Au cours des deux derniers chapitres (si vous avez manqué des chapitres, c’est par ici) Nadia Eghbal nous a décrit les solutions existantes pour financer les projets open source et leurs contributeurs : mécénat, crowdfunding, utilisation payante d’un logiciel ou d’un service ; elle a également montré les difficultés et les limites de chaque mode de financement.

Dans ce bref chapitre, l’autrice poursuit sa recherche sur les financements en faisant un point synthétique sur les causes systémiques des difficultés de financement des projets open source.

Traduction Framalang : Sphinx, Penguin, Opsylac, Luc, dominix, lyn., goofy

Pourquoi ces projets sont-ils si difficiles à financer ?

Aujourd’hui, le travail sur les infrastructures numériques est effectué par des développeurs freelance ou ayant un « job alimentaire », leur temps libre est consacré aux projets open source mais le reste du temps ils font un travail rémunéré sans rapport avec ces projets. Même si c’est un moyen réaliste pour financer son quotidien, cela ne permet pas d’apprécier à sa juste valeur l’apport social de ces projets.

Étonnamment, bien que tout le monde soit d’accord pour reconnaître qu’il y a un problème (qu’on le qualifie de « burnout du bénévole », de mauvaise gestion de la communauté ou de manque de financement suffisant), la discussion ne dépasse pas le stade de maigres solutions à court-terme comme les « pourboires » ou le crowdfunding.

Discutez avec des développeurs qui ont trouvé un moyen de gagner leur vie, et vous entendrez le mot « chanceux » à tout bout de champ : chanceux d’avoir été embauché par une entreprise, chanceux d’avoir eu de la notoriété et des dons, chanceux d’être tombé sur un modèle économique viable, chanceux de ne pas avoir une famille ou un prêt dont s’inquiéter. Tout le monde peut être chanceux. Mais la chance dure quelques mois, peut-être un an ou deux, et puis elle s’épuise.

Pourquoi est-il si difficile de financer les infrastructures numériques ?

Fondamentalement, l’infrastructure numérique a un problème de passagers clandestins. Les ressources sont disponibles gratuitement, et tout le monde les utilise (qu’il s’agisse de développeurs individuels ou de grandes entreprises de logiciels), mais personne n’est encouragé à contribuer en retour, chacun s’imaginant qu’un autre finira par le faire. S’il est laissé à l’abandon, ce problème mènera à une tragédie des communs.
En plus de l’enjeu macroéconomique des communs, il y a plusieurs raisons pour lesquelles le financement des infrastructures numériques est particulièrement compliqué. Ces raisons ont déjà été abordées au cours de cette étude, mais sont toutes résumées ici.

On croit à tort qu’il s’agit d’un « problème résolu ».

Même parmi les acteurs du secteur comme les entreprises de logiciels, la croyance est très répandue que l’open source est déjà correctement financée, ce qui rend d’autant plus difficile la levée de fonds. Certains projets d’infrastructure fonctionnent durablement, soit parce qu’ils disposent d’un modèle économique viable ou de mécènes, soit parce que les coûts de maintenance sont limités. Un public novice pourra également faire le lien entre l’open source et des entreprises telles que Red Hat ou Docker et penser que le problème a été résolu. Mais il faut garder à l’esprit que ces cas sont l’exception et non la règle.

Il manque une prise de conscience et une compréhension culturelle de ce problème.

En dehors de la communauté open source, tout le monde, ou presque, ignore les problèmes de financement de ces projets d’infrastructure, et le sujet est perçu comme plutôt aride et technique. Les développeurs qui ont besoin de soutien ont tendance à se concentrer principalement sur la technique et sont mal à l’aise lorsqu’il s’agit de défendre l’aspect financier de leur travail. Au bout du compte, on ne parvient pas à trouver l’élan qui pourrait modifier cette situation en panne.

Les infrastructures numériques sont enracinées dans l’open source, dont la culture du bénévolat n’encourage pas à parler d’argent.

Même si cette attitude a fait de l’open source ce qu’elle est aujourd’hui, elle crée également un tabou qui rend difficile pour les développeurs l’évocation de leurs besoins, car ils se sentent coupables ou ont peur de passer pour des personnes qui n’auraient pas l’esprit d’équipe. La nature hautement décentralisée et démocratique de l’Open source rend également difficile la coordination et le financement d’acteurs institutionnels qui pourraient défendre leurs intérêts.

 

Les infrastructures numériques sont hautement décentralisées, contrairement aux infrastructures physiques.

Contrairement à un projet de construction de pont, il n’est pas toujours évident de savoir quels projets seront utiles avant qu’ils n’aient déjà décollé. Ils ne peuvent pas être planifiés à l’avance par un organisme centralisé. Et à l’autre bout du cycle de vie, certains projets sont destinés à tomber en désuétude à mesure que d’autres solutions, meilleures, prendront leur place. L’infrastructure numérique est constituée de centaines de projets, grands ou petits, réalisés par des individus, des groupes ou des entreprises ; en faire l’inventaire serait un travail de titan.

 

« Il est difficile de trouver des financements… pour le développeur moyen (comme moi), certains sont totalement hors de portée. [Kickstarter] ne marche que si tu deviens viral, ou si tu embauches quelqu’un pour faire tout ce qui est marketing/design/promotion… Transformer un projet en entreprise c’est génial aussi mais… ce sont des choses qui t’éloignent du développement (qui est la partie qui m’intéresse). Si je voulais obtenir une subvention, je ne saurais même pas par où commencer. »

– Kyle Kemp, développeur freelance et contributeur open source.

 

Alors que la France s’apprête à accueillir le Sommet mondial du Partenariat pour un Gouvernement Ouvert, plusieurs associations pointent les contradictions du gouvernement. Certaines ne s’y rendront pas.

Bilan du gouvernement ouvert à la française (9 pages), co-signé par les associations et collectifs suivants : April, BLOOM, DemocracyOS France, Fais ta loi, Framasoft, La Quadrature du Net, Ligue des Droits de l’Homme, Regards Citoyens, République citoyenne, SavoirsCom1.

Derrière un apparent « dialogue avec la société civile », la France est loin d’être une démocratie exemplaire

Le « gouvernement ouvert » est une nouvelle manière de collaborer entre les acteurs publics et la société civile, pour trouver des solutions conjointes aux grands défis auxquels les démocraties font face : les droits humains, la préservation de l’environnement, la lutte contre la corruption, l’accès pour tous à la connaissance, etc.

Soixante-dix pays se sont engagés dans cette démarche en adhérant au Partenariat pour un Gouvernement Ouvert (PGO), qui exige de chaque État la conception et la mise en œuvre d’un Plan d’action national, en collaboration étroite avec la société civile.

La France a adhéré au Partenariat pour un Gouvernement Ouvert en avril 2014, et publié son premier Plan d’action national en juillet 2015. Depuis octobre 2016, le gouvernement français co-préside le PGO, avec l’association américaine WRI (World Resource Institute) et la France accueille le Sommet mondial du PGO à Paris, du 7 au 9 décembre 2016, présenté comme la « COP 21 de la démocratie ».

En tant que « pays des droits de l’Homme », nation co-présidente et hôte du Sommet mondial du PGO, on pourrait attendre de la France qu’elle donne l’exemple en matière de gouvernement ouvert.

Hélas, à ce jour, les actes n’ont pas été à la hauteur des annonces, y compris dans les trois domaines que la France elle-même considère prioritaires (1. Climat et développement durable ; 2. Transparence, intégrité et lutte contre la corruption ; 3. Construction de biens communs numériques) et ce, malgré l’autosatisfaction affichée du gouvernement. Pire, certaines décisions et pratiques, à rebours du progrès démocratique promu par le Partenariat pour un gouvernement ouvert, font régresser la France et la conduisent sur un chemin dangereux.

Les associations signataires de ce communiqué dressent un bilan critique et demandent au gouvernement et aux parlementaires de revoir certains choix qui s’avèrent radicalement incompatibles avec l’intérêt général et l’esprit du PGO, et de mettre enfin en cohérence leurs paroles et leurs actes.

Lire le bilan complet (9 pages).

Les co-signataires

L’April est la principale association de promotion et de défense du logiciel libre dans l’espace francophone. La mobilisation de ses bénévoles et de son équipe de permanents lui permet de mener des actions nombreuses et variées en faveur des libertés informatiques.

BLOOM, Fondée en 2005 par Claire Nouvian, BLOOM est entièrement dévouée aux océans et à ceux qui en vivent. Sa mission est d’œuvrer pour le bien commun en mettant en œuvre un pacte durable entre l’homme et la mer.

DemocracyOS France est une association qui promeut l’usage d’une plateforme web open source permettant de prendre des décisions de manière transparente et collective.

Fais Ta Loi est un collectif qui a pour but d’aider les publics les plus éloignés du débat démocratique à faire entendre leur voix au Parlement.

Framasoft est un réseau dédié à la promotion du « libre » en général et du logiciel libre en particulier.

Ligue des Droits de l’Homme  : agit pour la défense des droits et libertés, de toutes et de tous. Elle s’intéresse à la citoyenneté sociale et propose des mesures pour une démocratie forte et vivante, en France et en Europe.

La Quadrature du Net : La Quadrature du Net est une association de défense des droits et libertés des citoyens sur Internet.

Regards Citoyens est un collectif transpartisan né en 2009 qui promeut la transparence démocratique et l’ouverture des données publiques pour alimenter le débat politique. Il est a l’initiative d’une douzaine d’initiatives dont NosDeputés.fr et LaFabriqueDeLaLoi.fr.

République citoyenne est une association, créée en 2013, qui a pour but de stimuler l’esprit critique des citoyens sur les questions démocratiques et notamment sur le gouvernement ouvert.

SavoirsCom1 est un collectif dédié à la défense de politiques publiques en faveur des Communs de la connaissance.

 

Crédit image : Marie-Lan Nguyen (CC BY 2.0)

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.

Dans notre projet de traduction de l’ouvrage de Nadia Eghbal Roads and Bridges (tous les épisodes déjà traduits), nous abordons aujourd’hui une section importante consacrée aux modes de financement de ce qu’elle appelle l’infrastructure numérique et qui est comme l’épine dorsale de du monde informatique.

Elle donne ici un aperçu avec quelques exemples significatifs des trois principales voies explorées avec des succès variables par les développeurs et les entreprises : l’incitation par des récompenses, la monétisation par des services et le recours à des licences open source hybrides, en partie payantes…

Des modèles économiques pour les infrastructures numériques

Traduction Framalang : Piup, xi, Penguin, Bidouille, Lumibd, Opsylac, goofy

Certains aspects des infrastructures numériques peuvent fonctionner dans un contexte concurrentiel. Les bases de données et les services d’hébergement, par exemple, sont souvent des affaires profitables, bien financées, parce qu’elles peuvent faire payer l’accès. Tout comme l’accès à l’eau ou à l’électricité, l’accès à un serveur ou à une base de données peut être mesuré, facturé, et fermé si les honoraires ne sont pas réglés.

Heroku (mentionné au début de ce rapport) et Amazon Web Services sont deux exemples notables de plateformes qui vendent des services d’infrastructure numérique à des développeurs logiciels contre une redevance (à noter qu’aucun des deux n’est un projet open source). Des projets open source similaires, à ce niveau d’infrastructure, tels que OpenStack (une plate-forme concurrente d’Amazon Web Services) ou MySQL (une base de données), ont trouvé leurs assises dans des entreprises. OpenStack est financé par un consortium d’entreprises, et MySQL a été racheté par Oracle.

Une partie de ce qui rend ces services financièrement attractifs, c’est l’absence de « bruit ». Pour un seul logiciel, un développeur utilise parfois 20 bibliothèques différentes, avec chacune des fonctions différentes, mais il n’a besoin que d’une seule base de données. En conséquence, les projets à succès ont plus de chances d’obtenir l’attention et le soin dont ils ont besoin.

Il existe une autre façon utile de cerner les infrastructures que l’on peut facturer : s’il y a un risque immédiat de défaillance, alors il y a probablement un modèle économique. En d’autres termes, un serveur peut subir des interruptions de service inattendues, tout comme l’électricité peut sauter à l’improviste, mais un langage de programmation ne « casse » ni n’a des périodes d’indisponibilités de cette même façon, parce qu’il s’agit d’un système d’information.

Pour ce genre de projets open source, le modèle économique a tendance à se focaliser sur la recherche de services ou d’assistance facturables. Cela fonctionne pour les projets qui bénéficient d’un usage significatif par les entreprises, en particulier quand il s’agit d’un problème techniquement complexe, ou lorsqu’une entreprise a besoin qu’une fonction soit développée.

Récompenses

À petite échelle, des gens ou des entreprises promettent parfois des « récompenses » d’ordre pécuniaire pour l’atteinte de certains objectifs de développement.
Par exemple, IBM demande régulièrement de nouvelles fonctionnalités pour divers projets par le biais d’un site web appelé Bountysource, offrant jusqu’à 5 000 $ par tâche. Bountysource est une plateforme populaire pour trouver et proposer des récompenses ; elle compte plus de 26 000 membres. 120 récompenses aident à régler les problèmes précédemment mentionnés liés aux simples dons à un projet. Comme les récompenses sont clairement liées à un résultat, l’argent va être utilisé. En revanche, les récompenses peuvent avoir des effets pervers pour l’incitation à contribuer à un projet.
Les récompenses peuvent dicter quel travail sera ou ne sera pas effectué, et parfois ce travail n’est pas en phase avec les priorités d’un projet. Il peut aussi introduire du bruit dans le système : par exemple, une entreprise peut offrir une forte récompense pour une fonctionnalité que les propriétaires du projet ne considèrent pas comme importante.

Du côté des contributeurs, des personnes extérieures sans connaissances sur un projet peuvent y participer seulement pour obtenir la récompense, puis le quitter. Ou bien elles peuvent bâcler le travail requis, parce qu’elles essaient d’obtenir des récompenses. Enfin, les récompenses peuvent être une façon appropriée de financer de nouvelles fonctionnalités ou des problèmes importants, mais sont moins pratiques lorsqu’il s’agit de financer des opérations continues, comme le service client ou la maintenance.

Jeff Atwood, le créateur de Stack Overflow, a remarqué les problèmes suivants avec les programmes de récompenses, en particulier en ce qui concerne la sécurité :

L’un des effets pervers de cette tendance à attribuer des récompenses pour les rapports de bugs est que cela n’attire pas seulement de véritables programmeurs intéressés par la sécurité, mais aussi tous les gens intéressés par l’argent facile. Nous avons reçu trop de rapports de bugs de sécurité « sérieux » qui n’avaient qu’une importance très faible. Et nous devons les traiter, parce qu’ils sont « sérieux », n’est-ce pas ? Malheureusement, beaucoup d’entre eux ne représentent qu’un gaspillage de temps… Ce genre d’incitation me semble mauvais. Même si je sais que la sécurité est extrêmement importante, je vois ces interactions avec de plus en plus d’inquiétude parce qu’elles me créent beaucoup de travail et que le retour sur investissement est très faible.

Services

À une plus vaste échelle, un des exemples bien connus et les plus souvent cités de modèle économique open source, c’est Red Hat, l’entreprise dont nous avons déjà parlé, qui propose une assistance, des sessions de formation et autres services à des entreprises qui utilisent Linux. Red Hat a été fondée en 1993, il s’agit d’une entreprise cotée en bourse avec un chiffre d’affaires déclaré de 2 milliards de dollars par an.

Bien que Red Hat ait connu un succès fantastique d’un point de vue financier, nombreux sont ceux qui soulignent qu’il s’agit d’une anomalie qui n’aura pas de lendemains. Red Hat a bénéficié de l’avantage du premier arrivé dans son domaine technologique. Matt Asay, un journaliste spécialisé en open source, a remarqué que Red Hat utilise un ensemble unique de licences et brevets pour protéger ses parts de marché. Asay, qui auparavant était un fervent défenseur des entreprises open source, est maintenant persuadé que certaines licences propriétaires sont nécessaires pour faire sérieusement des affaires. Matthew Aslet du 451 Group, un organisme de recherche, a découvert lui aussi que la plupart des entreprises open source qui réussissent utilisent en fait un type ou un autre de licence commerciale.

Docker, déjà mentionné plus haut, est un projet open source qui aide les applications à fonctionner efficacement. C’est l’exemple le plus récent d’entreprise qui s’inspire de ce modèle. Docker a levé 180 millions de dollars en capital-risque auprès d’investisseurs, avec une valorisation d’un milliard de dollars de la part d’investisseurs privés. Comme sa part de marché s’est accrue, Docker a commencé à proposer des services d’assistance au niveau des entreprises. Mais sans solides revenus, Docker pourrait n’être qu’un exemple de plus de capital-risque qui fait un investissement dans une entreprise d’infrastructure leader sur son marché, mais qui réalise des pertes.

À petite échelle, beaucoup de développeurs proposent des services de consultants pour pouvoir financer leur travail. Hoodie est un framework poids plume qui repose sur Node et qui a réussi dans les services de consultants.

Hoodie lui-même est un projet open source. Plusieurs mainteneurs gagnent leur vie grâce à la boutique de l’entreprise, Neighbourhoodie, qui propose des services de développement logiciel. Bien que Neighbourhoodie se spécialise dans le framework de Hoodie, ce dernier est encore un projet plutôt jeune, de sorte que certaines parties de son travail proviennent de pojets qui ne sont pas lié à Hoodie. Dans le cas de Hoodie, le modèle de services choisi est censé payer le salaire de plusieurs mainteneurs, plutôt que de viser une stratégie d’entreprise de l’échelle de Red Hat.

Le conseil est une option viable pour les développeurs indépendants, s’il y a suffisamment de gens qui utilisent le projet qui sont d’accord et ont assez d’argent pour payer de l’aide supplémentaire. Mais à petite échelle, cela peut aussi les empêcher d’améliorer le projet lui-même, puisque les deux personnes au plus qui le maintiennent passent désormais leur temps à développer leur affaire et à fournir des services qui peuvent ou non être en accord avec les besoins du projet en termes de maintenance.

Aspirer à une activité de consultant peut aussi entrer en contradiction avec l’objectif de rendre le produit facile à utiliser et à appréhender, ce qui est bien dans l’esprit de l’open source. Twisted, la bibliothèque Python déjà citée, a mentionné un témoignage plein d’humour de l’un de ses utilisateurs, une entreprise nommée Mailman : « Les gars, vous avez un gros problème, parce que c’était vraiment trop facile ! Comment vous comptez vous faire un paquet d’argent juste avec du conseil ? :) »

En fin de compte, le « modèle économique » pour un projet open source n’est pas très différent du simple travail indépendant.

Licences payantes

Certains développeurs ont l’impression que mettre les projets sous licence serait une solution au moins partielle aux problèmes de financement de l’open source. Si les projets open source sont fortement utilisés, pourquoi ne pas les facturer ? Ces « licences payantes » ne sont techniquement pas des licences open source, selon la définition de l’open source Initiative. Il s’agit plutôt d’initiatives qui tentent d’apporter un équilibre entre le besoin très concret de travail rémunéré et le désir de rendre le code accessible au public. Ce type de code peut être appelé « à source visible » ou «  à source disponible ». Fair Source, par exemple, se décrit lui-même comme «  [offrant] certains des avantages de l’open source tout en préservant la possibilité de faire payer pour le logiciel. »

La licence Fair Source fut créée en novembre 2015 par une entreprise appelée Sourcegraph pour répondre au besoin de licence payante. Les termes de la licence ont été rédigés par Heather Meeker, un juriste qui a également travaillé dans l’équipe principale de la Mozilla Public License v2.0. Avec la licence Fair Source, on peut librement consulter, télécharger, exécuter et modifier le code, jusqu’à un certain nombre d’utilisateurs par organisation. Une fois cette limite dépassée, l’organisation doit payer un forfait de licence, dont le montant est déterminé par l’éditeur. En d’autres termes, le code Fair Source est gratuit pour un usage personnel et pour les PME, mais fournit une base légale pour facturer les cas de plus gros usages commerciaux.

L’annonce par Sourcegraph de la création de la licence Fair Source, qu’ils utilisent maintenant eux-mêmes, a provoqué un débat animé sur la monétisation de l’open source. (Il est à noter qu’un mouvement similaire autour du « shareware », logiciel propriétaire gratuit, avait émergé avec un certain succès populaire dans les années 1980).
Mike Perham, l’un des mainteneurs de Sidekiq, un outil populaire pour le développement en Ruby, a aussi récemment suggéré aux contributeurs et contributrices open source d’utiliser une «  licence duale » pour monétiser leur travail, faisant payer les entreprises l’accès à une licence MIT permissive plutôt qu’une licence AGPL plus restrictive qui impose l’attribution. Sa théorie est qu’en faisant d’AGPL la licence par défaut, « les entreprises vont payer pour l’éviter. »
Pour justifier cette idée, Perham a rappelé à son public :

«  Souvenez-vous : logiciel open source ne signifie pas logiciel gratuit. Ce n’est pas parce que l’on peut consulter la source sur GitHub que tout le monde peut l’utiliser et en faire n’importe quoi. Il n’y a aucune raison pour laquelle vous ne pourriez pas donner l’accès à votre code mais aussi faire payer pour son utilisation. Tant que vous possédez le code, vous avez le droit d’y attribuer la licence que vous voulez.
…[La] réalité, c’est que la plupart des petits projets open source dépendent d’une seule personne qui fait 95 % du travail. Si c’est votre cas, soyez reconnaissants envers les gens qui vous aident gratuitement mais ne vous sentez pas coupable de garder 100 % du revenu. »

Faire payer les entreprises offre une autre possibilité aux développeurs et développeuses qui souhaitent poursuivre leur travail, en particulier s’il n’y a qu’une ou deux personnes pour maintenir un projet actif. Cependant, tous les projets ne peuvent pas faire payer pour le travail fourni, en particulier les projets plus vieux, ou les projets d’infrastructure qui ressemblent plus à des biens publics qu’à des produits de consommation, comme les langages de programmation.

Même si les licences payantes peuvent fonctionner pour certains scénarios, ce modèle est aussi pour beaucoup en opposition avec l’énorme valeur sociale offerte par l’open source, qui suggère que lorsque le logiciel est libre, l’innovation suit.

L’objectif ne devrait pas être le retour à une société qui repose sur les logiciels fermés, où le progrès et la créativité sont limités, mais de soutenir de façon durable un écosystème public dans lequel le logiciel peut être créé et distribué librement.

Cet article vise à clarifier la position de Framasoft, sollicitée à plusieurs reprises par le Ministère de l’Éducation Nationale ces derniers mois. Malgré notre indignation, il ne s’agit pas de claquer la porte, mais au contraire d’en ouvrir d’autres vers des acteurs qui nous semblent plus sincères dans leur choix du libre et ne souhaitent pas se cacher derrière une « neutralité et égalité de traitement » complètement biaisée par l’entrisme de Google, Apple ou Microsoft au sein de l’institution.

Pour commencer

Une technologie n’est pas neutre, et encore moins celui ou celle qui fait des choix technologiques. Contrairement à l’affirmation de la Ministre de l’Éducation Mme Najat Vallaud-Belkacem, une institution publique ne peut pas être « neutre technologiquement », ou alors elle assume son incompétence technique (ce qui serait grave). En fait, la position de la ministre est un sophisme déjà bien ancien ; c’est celui du Gorgias de Platon qui explique que la rhétorique étant une technique, il n’y en a pas de bon ou de mauvais usage, elle ne serait qu’un moyen.

Or, lui oppose Socrate, aucune technique n’est neutre : le principe d’efficacité suppose déjà d’opérer des choix, y compris économiques, pour utiliser une technique plutôt qu’une autre ; la possession d’une technique est déjà en soi une position de pouvoir ; enfin, rappelons l’analyse qu’en faisait Jacques Ellul : la technique est un système autonome qui impose des usages à l’homme qui en retour en devient addict. Même s’il est consternant de rappeler de tels fondamentaux à ceux qui nous gouvernent, tout choix technologique suppose donc une forme d’aliénation. En matière de logiciels, censés servir de supports dans l’Éducation Nationale pour la diffusion et la production de connaissances pour les enfants, il est donc plus qu’évident que choisir un système plutôt qu’un autre relève d’une stratégie réfléchie et partisane.

Un système d’exploitation n’est pas semblable à un autre, il suffit pour cela de comparer les deux ou trois principaux OS du marché (privateur) et les milliers de distributions GNU/Linux, pour comprendre de quel côté s’affichent la créativité et l’innovation. Pour les logiciels en général, le constat est le même : choisir entre des logiciels libres et des logiciels privateurs implique une position claire qui devrait être expliquée. Or, au moins depuis 1997, l’entrisme de Microsoft dans les organes de l’Éducation Nationale a abouti à des partenariats et des accords-cadres qui finirent par imposer les produits de cette firme dans les moindres recoins, comme s’il était naturel d’utiliser des solutions privatrices pour conditionner les pratiques d’enseignement, les apprentissages et in fine tous les usages numériques. Et ne parlons pas des coûts que ces marchés publics engendrent, même si les solutions retenues le sont souvent, au moins pour commencer, à « prix cassé ».

Depuis quelque temps, au moins depuis le lancement de la première vague de son projet Degooglisons Internet, Framasoft a fait un choix stratégique important : se tourner vers l’éducation populaire, avec non seulement ses principes, mais aussi ses dynamiques propres, ses structures solidaires et les valeurs qu’elle partage. Nous ne pensions pas que ce choix pouvait nous éloigner, même conceptuellement, des structures de l’Éducation Nationale pour qui, comme chacun le sait, nous avons un attachement historique. Et pourtant si… Une rétrospective succincte sur les relations entre Microsoft et l’Éducation Nationale nous a non seulement donné le tournis mais a aussi occasionné un éclair de lucidité : si, malgré treize années d’(h)activisme, l’Éducation Nationale n’a pas bougé d’un iota sa préférence pour les solutions privatrices et a même radicalisé sa position récemment en signant un énième partenariat avec Microsoft, alors nous utiliserions une partie des dons, de notre énergie et du temps bénévole et salarié en pure perte dans l’espoir qu’il y ait enfin une position officielle et des actes concrets en faveur des logiciels libres. Finalement, nous en sommes à la fois indignés et confortés dans nos choix.

L’Éducation Nationale et Microsoft, une (trop) longue histoire

En France, les rapports qu’entretient le secteur de l’enseignement public avec Microsoft sont assez anciens. On peut remonter à la fin des années 1990 où eurent lieu les premiers atermoiements à l’heure des choix entre des solutions toutes faites, clés en main, vendues par la société Microsoft, et des solutions de logiciels libres, nécessitant certes des efforts de développement mais offrant à n’en pas douter, des possibilités créatrices et une autonomie du service public face aux monopoles économiques. Une succession de choix délétères nous conduisent aujourd’hui à dresser un tableau bien négatif.

Dans un article paru dans Le Monde du 01/10/1997, quelques mois après la réception médiatisée de Bill Gates par René Monory, alors président du Sénat, des chercheurs de l’Inria et une professeure au CNAM dénonçaient la mainmise de Microsoft sur les solutions logicielles retenues par l’Éducation Nationale au détriment des logiciels libres censés constituer autant d’alternatives fiables au profit de l’autonomie de l’État face aux monopoles américains. Les mots ne sont pas tendres :

(…) Microsoft n’est pas la seule solution, ni la meilleure, ni la moins chère. La communauté internationale des informaticiens développe depuis longtemps des logiciels, dits libres, qui sont gratuits, de grande qualité, à la disposition de tous, et certainement beaucoup mieux adaptés aux objectifs, aux besoins et aux ressources de l’école. Ces logiciels sont largement préférés par les chercheurs, qui les utilisent couramment dans les contextes les plus divers, et jusque dans la navette spatiale. (…) On peut d’ailleurs, de façon plus générale, s’étonner de ce que l’administration, et en particulier l’Éducation Nationale, préfère acheter (et imposer à ses partenaires) des logiciels américains, plutôt que d’utiliser des logiciels d’origine largement européenne, gratuits et de meilleure qualité, qui préserveraient notre indépendance technologique.

L’année suivante, en octobre 1998, le Ministère de l’Éducation Nationale signe avec l’AFUL un accord-cadre pour l’exploitation, le développement et l’expertise de solutions libres dans les établissements. Le Ministère organise même en juillet 1999 une Université d’été « La contribution des logiciels et ressources libres à l’amélioration de l’environnement de travail des enseignants et des élèves sur les réseaux ».

D’autres témoignages mettent en lumière des tensions entre logiciels libres et logiciels privateurs dans les décisions d’équipement et dans les intentions stratégiques de l’Éducation Nationale au tout début des années 2000. En revanche, en décembre 2003, l’accord-cadre¹ Microsoft et le Ministère de l’Éducation Nationale change radicalement la donne et propose des solutions clés en main intégrant trois aspects :

• tous les établissements de l’Éducation Nationale sont concernés, des écoles primaires à l’enseignement supérieur ;
• le développement des solutions porte à la fois sur les systèmes d’exploitation et la bureautique, c’est-à-dire l’essentiel des usages ;
• la vente des logiciels se fait avec plus de 50 % de remise, c’est-à-dire avec des prix résolument tirés vers le bas.

Depuis lors, des avenants à cet accord-cadre sont régulièrement signés. Comme si cela ne suffisait pas, certaines institutions exercent leur autonomie et établissent de leur côté des partenariats « en surplus », comme l’Université Paris Descartes le 9 juillet 2009, ou encore les Villes, comme Mulhouse qui signe un partenariat Microsoft dans le cadre de « plans numériques pour l’école », même si le budget est assez faible comparé au marché du Ministère de l’Éducation.

Il serait faux de prétendre que la société civile ne s’est pas insurgée face à ces accords et à l’entrisme de la société Microsoft dans l’enseignement. On ne compte plus les communiqués de l’April (souvent conjoints avec d’autres associations du Libre) dénonçant ces pratiques. Bien que des efforts financiers (discutables) aient été faits en faveur des logiciels libres dans l’Éducation Nationale, il n’en demeure pas moins que les pratiques d’enseignement et l’environnement logiciel des enfants et des étudiants sont soumis à la microsoftisation des esprits, voire une Gafamisation car la firme Microsoft n’est pas la seule à signer des partenariats dans ce secteur. Le problème ? Il réside surtout dans le coût cognitif des outils logiciels qui, sous couvert d’apprentissage numérique, enferme les pratiques dans des modèles privateurs : « Les enfants qui ont grandi avec Microsoft, utiliseront Microsoft ».

On ne saurait achever ce tableau sans mentionner le plus récent partenariat Microsoft-EN signé en novembre 2015 et vécu comme une véritable trahison par, entre autres, beaucoup d’acteurs du libre. Il a en effet été signé juste après la grande consultation nationale pour le Projet de Loi Numérique porté par la ministre Axelle Lemaire. La consultation a fait ressortir un véritable plébiscite en faveur du logiciel libre dans les administrations publiques et des amendements ont été discutés dans ce sens, même si le Sénat a finalement enterré l’idée. Il n’en demeure pas moins que les défenseurs du logiciel libre ont cru déceler chez nombre d’élus une oreille attentive, surtout du point de vue de la souveraineté numérique de l’État. Pourtant, la ministre Najat Vallaud-Belkacem a finalement décidé de montrer à quel point l’Éducation Nationale ne saurait être réceptive à l’usage des logiciels libre en signant ce partenariat, qui constitue, selon l’analyse par l’April des termes de l’accord, une « mise sous tutelle de l’informatique à l’école » par Microsoft.

Entre libre-washing et méthodes douteuses

Pour être complète, l’analyse doit cependant rester honnête : il existe, dans les institutions de l’Éducation Nationale des projets de production de ressources libres. On peut citer par exemple le projet EOLE (Ensemble Ouvert Libre Évolutif), une distribution GNU/Linux basée sur Ubuntu, issue du Pôle de compétence logiciel libre, une équipe du Ministère de l’Éducation Nationale située au rectorat de l’académie de Dijon. On peut mentionner le projet Open Sankoré, un projet de développement de tableau interactif au départ destiné à la coopération auprès de la Délégation Interministérielle à l’Éducation Numérique en Afrique (DIENA), repris par la nouvelle Direction du numérique pour l’éducation (DNE) du Ministère de l’EN, créée en 2014. En ce qui concerne l’information et la formation des personnels, on peut souligner certaines initiatives locales comme le site Logiciels libres et enseignement de la DANE (Délégation Académique au Numérique Éducatif) de l’académie de Versailles. D’autres projets sont parfois maladroits comme la liste de « logiciels libres et gratuits » de l’académie de Strasbourg, qui mélange allègrement des logiciels libres et des logiciels privateurs… pourvus qu’ils soient gratuits.

Les initiatives comme celles que nous venons de recenser se comptent néanmoins sur les doigts des deux mains. En pratique, l’environnement des salles informatiques des lycées et collèges reste aux couleurs Microsoft et les tablettes (réputées inutiles) distribuées çà et là par villes et départements, sont en majorité produites par la firme à la pomme². Les enseignants, eux, n’ayant que très rarement voix au chapitre, s’épuisent souvent à des initiatives en classe fréquemment isolées bien que créatives et efficaces. Au contraire, les inspecteurs de l’Éducation Nationale sont depuis longtemps amenés à faire la promotion des logiciels privateurs quand ils ne sont pas carrément convoqués chez Microsoft.

L’interprétation balance entre deux possibilités. Soit l’Éducation Nationale est composée exclusivement de personnels incohérents prêts à promouvoir le logiciel libre partout mais ne faisant qu’utiliser des suites Microsoft. Soit des projets libristes au sein de l’Éducation Nationale persistent à exister, composés de personnels volontaires et motivés, mais ne s’affichent que pour mieux mettre en tension les solutions libres et les solutions propriétaires. Dès lors, comme on peut s’attendre à ce que le seul projet EOLE ne puisse assurer toute une migration de tous les postes de l’EN à un système d’exploitation libre, il est logique de voir débouler Microsoft et autres sociétés affiliées présentant des solutions clés en main et économiques. Qu’a-t-on besoin désormais de conserver des développeurs dans la fonction publique puisque tout est pris en charge en externalisant les compétences et les connaissances ? Pour que cela ne se voie pas trop, on peut effectivement s’empresser de mettre en avant les quelques deniers concédés pour des solutions libres, parfois portées par des sociétés à qui on ne laisse finalement aucune chance, telle RyXéo qui proposait la suite Abulédu.

Finalement, on peut en effet se poser la question : le libre ne serait-il pas devenu un alibi, voire une caution bien mal payée et soutenue au plus juste, pour légitimer des solutions privatrices aux coûts exorbitants ? Les décideurs, DSI et autres experts, ne préfèrent-ils pas se reposer sur un contrat Microsoft plutôt que sur le management de développeurs et de projets créatifs ? Les solutions les plus chères sont surtout les plus faciles.

Plus faciles, mais aussi plus douteuses ! On pourra en effet se pencher à l’envi sur les relations discutables entre certains cadres de Microsoft France et leurs postes occupés aux plus hautes fonctions de l’État, comme le montrait le Canard Enchaîné du 30 décembre 2015. Framasoft se fait depuis longtemps l’écho des manœuvres de Microsoft sans que cela ne soulève la moindre indignation chez les décideurs successifs au Ministère³. On peut citer, pêle-mêle :

• la stratégie sournoise d’introduction des produits à l’école, selon la technique « embrace and extend », ce qui flirte dangereusement avec les règlements en vigueur, à commencer par le droit des marchés publics (opposé régulièrement pour contrecarrer la préférence donnée au Libre dans les appels d’offres) ;
• les accointances institutionnelles et le mélange des genres savamment orchestré ;
• les frontières imprécises entre promotion marketing et innovation pédagogique, voilant à peine les intentions réelles de Microsoft…

 

Du temps et de l’énergie en pure perte

« Vous n’avez qu’à proposer », c’est en substance la réponse balourde par touittes interposés de Najat Vallaud-Belkacem aux libristes qui dénonçaient le récent accord-cadre signé entre Microsoft et le Ministère. Car effectivement, c’est bien la stratégie à l’œuvre : alors que le logiciel libre suppose non seulement une implication forte des décideurs publics pour en adopter les usages, son efficience repose également sur le partage et la contribution. Tant qu’on réfléchit en termes de pure consommation et de fournisseur de services, le logiciel libre n’a aucune chance. Il ne saurait être adopté par une administration qui n’est pas prête à développer elle-même (ou à faire développer) pour ses besoins des logiciels libres et pertinents, pas plus qu’à accompagner leur déploiement dans des milieux qui ne sont plus habitués qu’à des produits privateurs prêts à consommer.

Au lieu de cela, les décideurs s’efforcent d’oublier les contreparties du logiciel libre, caricaturent les désavantages organisationnels des solutions libres et légitiment la Microsoft-providence pour qui la seule contrepartie à l’usage de ses logiciels et leur « adaptation », c’est de l’argent… public. Les conséquences en termes de hausses de tarifs des mises à jour, de sécurité, de souveraineté numérique et de fiabilité, par contre, sont des sujets laissés vulgairement aux « informaticiens », réduits à un débat de spécialistes dont les décideurs ne font visiblement pas partie, à l’instar du Ministère de la défense lui aussi aux prises avec Microsoft.

Comme habituellement il manque tout de même une expertise d’ordre éthique, et pour peu que des compétences libristes soient nécessaires pour participer au libre-washing institutionnel, c’est vers les associations que certains membres de l’Éducation Nationale se tournent. Framasoft a bien souvent été démarchée soit au niveau local pour intervenir dans des écoles / collèges / lycées afin d’y sensibiliser au Libre, soit pour collaborer à des projets très pertinents, parfois même avec des possibilités de financement à la clé. Ceci depuis les débuts de l’association qui se présente elle-même comme issue du milieu éducatif.

Depuis plus de dix ans Framasoft intervient sur des projets concrets et montre par l’exemple que les libristes sont depuis longtemps à la fois forces de proposition et acteurs de terrain, et n’ont rien à prouver à ceux qui leur reprocheraient de se contenter de dénoncer sans agir. Depuis deux décennies des associations comme l’April ont impulsé des actions, pas seulement revendicatrices mais aussi des conseils argumentés, de même que l’AFUL (mentionnée plus haut). Las… le constat est sans appel : l’Éducation Nationale a non seulement continué à multiplier les relations contractuelles avec des firmes comme Microsoft, barrant la route aux solutions libres, mais elle a radicalisé sa position en novembre 2015 en un ultime pied de nez à ces impertinentes communautés libristes.

Nous ne serons pas revanchards, mais il faut tout de même souligner que lorsque des institutions publiques démarchent des associations composées de membres bénévoles, les tâches demandées sont littéralement considérées comme un dû, voire avec des obligations de rendement. Cette tendance à amalgamer la soi-disant gratuité du logiciel libre et la soi-disant gratuité du temps bénévole des libristes, qu’il s’agisse de développement ou d’organisation, est particulièrement détestable.

Discuter au lieu de faire

À quelles demandes avons-nous le plus souvent répondu ? Pour l’essentiel, il s’agit surtout de réunions, de demandes d’expertises dont les résultats apparaissent dans des rapports, de participation plus ou moins convaincante (quand il s’agit parfois de figurer comme caution) à des comités divers, des conférences… On peut discuter de la pertinence de certaines de ces sollicitations tant les temporalités de la réflexion et des discours n’ont jamais été en phase avec les usages et l’évolution des pratiques numériques.

Le discours de Framasoft a évolué en même temps que grandissait la déception face au décalage entre de timides engagements en faveur du logiciel libre et des faits attestant qu’à l’évidence le marché logiciel de l’Éducation Nationale était structuré au bénéfice des logiques privatrices. Nous en sommes venus à considérer que…

• si, en treize ans de sensibilisation des enseignants et des décideurs, aucune décision publique n’a jamais assumé de préférence pour le logiciel libre ;
• si, en treize ans, le discours institutionnel s’est même radicalisé en défaveur du Libre : en 2003, le libre n’est « pas souhaitable » ; en 2013 le libre et les formats ouverts pourraient causer des « difficultés juridiques » ; en 2016, le libre ne pourra jamais être prioritaire malgré le plébiscite populaire⁴…

…une association comme Framasoft ne peut raisonnablement continuer à utiliser l’argent de ses donateurs pour dépenser du temps bénévole et salarié dans des projets dont les objectifs ne correspondent pas aux siens, à savoir la promotion et la diffusion du Libre.

L’éducation populaire : pas de promesses, des actes

Framasoft s’est engagée depuis quelque temps déjà dans une stratégie d’éducation populaire. Elle repose sur les piliers suivants :

• social : le mouvement du logiciel libre est un mouvement populaire où tout utilisateur est créateur (de code, de valeur, de connaissance…) ;
• technique : par le logiciel libre et son développement communautaire, le peuple peut retrouver son autonomie numérique et retrouver savoirs et compétences qui lui permettront de s’émanciper ;
• solidaire : le logiciel libre se partage, mais aussi les compétences, les connaissances et même les ressources. Le projet CHATONS démontre bien qu’il est possible de renouer avec des chaînes de confiance en mobilisant des structures au plus proche des utilisateurs, surtout si ces derniers manquent de compétences et/ou d’infrastructures.

Quelles que soient les positions institutionnelles, nous sommes persuadés qu’en collaborant avec de petites ou grandes structures de l’économie sociale et solidaire (ESS), avec le monde culturel en général, nous touchons bien plus d’individus. Cela sera également bien plus efficace qu’en participant à des projets avec le Ministère de l’Éducation Nationale, qui se révèlent n’avoir au final qu’une portée limitée. Par ailleurs, nous sommes aussi convaincus que c’est là le meilleur moyen de toucher une grande variété de publics, ceux-là mêmes qui s’indigneront des pratiques privatrices de l’Éducation Nationale.

Néanmoins, il est vraiment temps d’agir, car même le secteur de l’ESS commence à se faire « libre-washer » et noyauter par Microsoft : par exemple la SocialGoodWeek a pour partenaires MS et Facebook ; ou ADB Solidatech qui équipe des milliers d’ordinateurs pour associations avec des produits MS à prix cassés.

Ce positionnement du « faire, faire sans eux, faire malgré eux » nous a naturellement amenés à développer notre projet Degooglisons Internet. Mais au-delà, nous préférons effectivement entrer en relation directe avec des enseignants éclairés qui, plutôt que de perdre de l’énergie à convaincre la pyramide hiérarchique kafkaïenne, s’efforcent de créer des projets concrets dans leurs (minces) espaces de libertés. Et pour cela aussi le projet Degooglisons Internet fait mouche.

Nous continuerons d’entretenir des relations de proximité et peut-être même d’établir des projets communs avec les associations qui, déjà, font un travail formidable dans le secteur de l’Éducation Nationale, y compris avec ses institutions, telles AbulEdu, Sésamath et bien d’autres. Il s’agit là de relations naturelles, logiques et même souhaitables pour l’avancement du Libre. Fermons-nous définitivement la porte à l’Éducation Nationale ? Non… nous inversons simplement les rôles.

Pour autant, il est évident que nous imposons implicitement des conditions : les instances de l’Éducation Nationale doivent considérer que le logiciel libre n’est pas un produit mais que l’adopter, en plus de garantir une souveraineté numérique, implique d’en structurer les usages, de participer à son développement et de généraliser les compétences en logiciels libres. Dans un système déjà noyauté (y compris financièrement) par les produits Microsoft, la tâche sera rude, très rude, car le coût cognitif est déjà cher payé, dissimulé derrière le paravent brumeux du droit des marchés publics (même si en la matière des procédures négociées peuvent très bien être adaptées au logiciel libre). Ce n’est pas (plus) notre rôle de redresser la barre ou de cautionner malgré nous plus d’une décennie de mauvaises décisions pernicieuses.

Si l’Éducation Nationale décide finalement et officiellement de prendre le bon chemin, avec force décrets et positions de principe, alors, ni partisans ni vindicatifs, nous l’accueillerons volontiers à nos côtés car « la route est longue, mais la voie est libre… ».

— L’association Framasoft