Entretien avec Cédric Moreau, développeur d'outils pour les monnaies libres

Rédigé par Carl Chenet - -
Cédric Moreau, lead dev Duniter

Jdh : Bonjour Cédric et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Cédric : Bonjour Carl, et merci pour cette interview. Je m'appelle Cédric Moreau alias cgeek. Je suis un ingénieur en automatique et informatique de 29 ans, et surtout je suis développeur depuis mes 18 ans. Je vis sur Rennes avec ma compagne, et aussi j'ai un chat.

J'ai débuté ma vie post-études par 3 années de salariat en SSII, dans lesquelles j'ai commencé par maintenir puis produire des applications Java et JavaEE principalement. La 3ème année, donc 2015, fut l'occasion pour moi de travailler à 100% avec mon langage favori du moment : le JavaScript, sur Node.js.

Depuis 1 an, donc mars 2016, je suis freelance : j'ai créé ma société l'EURL Art et Zerty. Je continue de travailler pour des SSII, mais je me sens plus libre !

Mais le plus intéressant pour le Journal du hacker, c'est que je développe depuis l'été 2013 le logiciel Duniter, premier logiciel de l'histoire (un logiciel libre bien entendu) à permettre la production d'une monnaie libre décentralisée. Je suis le fondateur de ce logiciel et aussi le principal développeur. C'est mon fil rouge depuis bientôt 4 ans, et je crois bien qu'il le restera jusqu'à la fin de ma vie désormais.

Jdh : La monnaie semble prendre depuis quelques années une place grandissante dans l'informatique moderne. On pense immédiatement aux crypto-monnaies, comme le Bitcoin. Peux-tu rapidement nous préciser ce que tu entends par "monnaie libre" et ce que permet Duniter ?

Cédric : La « monnaie libre » est un concept nouveau, de la même façon qu'a pu l'être le logiciel libre dans les années 1980. Il y a d'ailleurs de grandes similitudes entre ces deux concepts car tous deux s'attachent aux libertés de l'utilisateur ; celles logicielles pour le logiciel libre et celles économiques pour la monnaie libre, et définissent quatre libertés fondamentales : les unes logicielles, les autres économiques.

Résumons ces quatre libertés pour la monnaie libre :

  • l'utilisateur est libre de choisir la monnaie
  • l'utilisateur est libre d'accéder aux ressources
  • l'utilisateur est libre d'estimer ce qui est valeur ou pas
  • l'utilisateur est libre d'échanger « dans la monnaie »

Attention : les mots ont beaucoup de sens et je dois ici les préciser. Notamment il faut bien comprendre que « libre » ne signifie pas « n'importe quoi » et que donc par exemple, dire que l'utilisateur est libre d'accéder aux ressources ne signifie pas qu'il pourrait s'approprier toutes les ressources et qu'il n'en reste plus pour les autres. La liberté se définit ici comme non-nuisance : c'est-à-dire que tout utilisateur devrait pouvoir accéder aux ressources, tout en laissant suffisamment de celle-ci en qualité et quantité pour les autres utilisateurs. Ou encore pour la liberté 1, ce n'est pas parce qu'un utilisateur choisit une monnaie que celle-ci devrait s'imposer aux autres.

De même, il ne faudrait pas tomber dans le piège logique qui consisterait à croire que la monnaie libre garantirait ces libertés, au sens où elle forcerait leur application. Il serait par exemple erroné de penser qu'adopter une monnaie libre vous permettrait immédiatement de récupérer l'or qui se trouve chez votre voisin.

Non : une monnaie est dite « libre » si elle est compatible avec ces 4 libertés, c'est-à-dire si son code monétaire ne les bafoue pas. Par exemple l'euro n'est pas une monnaie libre car elle a cours légal, elle est donc imposée. De même l'or ou le Bitcoin ne sont pas des monnaies libres puisque ce sont principalement les « mineurs » qui la produisent : les libertés 2, 3 et 4 ne sont pas respectées.

Enfin il faut bien comprendre que l'on parle ici de « monnaie libre » au sens défini par la Théorie Relative de la Monnaie (TRM), un ouvrage réalisé et publié sous licence GPLv3 par l'ingénieur Stéphane Laborde. De même que « logiciel libre » référence le sens défini par rms. Il ne faut donc pas s'offusquer que cette définition ne soit pas celle que pourraient imaginer d'autres personnes, par exemple celles qui diraient plutôt qu'une monnaie est dite « libre » si elle peut être produite par n'importe qui. C'est un point de vue possible, mais il se trouve que la définition qui nous intéresse est celle donnée par la TRM. C'est donc notre point de départ.

Que vient faire Duniter là-dedans ? Eh bien tout simplement : il permet de réaliser une monnaie libre. En termes de POO, on peut dire que Duniter implémente la monnaie libre telle que définie par la TRM.

Le logo de Duniter

Jdh : Si je comprends bien Duniter est la boîte à outil pour créer une (et pas "la") monnaie libre ? J'imagine donc que la création d'une monnaie libre est l'un de vos objectifs. Où en êtes-vous à ce niveau ?

Cédric : Oui, « une » monnaie libre. Car la monnaie libre n'est pas forcément numérique, ni même n'a besoin de Duniter pour fonctionner. Par exemple, des personnes souhaitant réaliser dès à présent une monnaie libre papier peuvent le faire.

Mais le problème du papier est que cela est coûteux à mettre en place, à la fois en temps et en ressources. Qui plus est, afin de vérifier que les billets papiers sont bien émis selon un Dividende Universel et qu'il n'existe pas des membres émettant de faux billets, il faut à un moment exercer un contrôle par l'informatique. Démarrer directement avec un système informatique est en réalité bien plus simple et accessible, surtout si l'on souhaite une monnaie avec un nombre conséquent d'utilisateurs qu'il faut par ailleurs eux-mêmes contrôler pour vérifier qu'il n'existe pas de double compte, et qui permettraient à leur auteur de produire plus de monnaie que les autres. Cette mécanique de vérification d'unicité des membres s'appelle « Toile de Confiance ».

Il faut bien comprendre : la toile de confiance est propre à Duniter, ce n'est pas une propriété d'une monnaie libre. Il se trouve que la monnaie libre implique d'avoir des individus identifiés pour la production du Dividende Universel, c'est pourquoi Duniter établit la toile de confiance. Mais bien d'autres systèmes pourraient exister.

Et donc, où en est-on ? Eh bien, après 3 ans et demi de développements, le 8 mars 2017 à 16h32, nous avons lancé la toute première monnaie propulsée par Duniter ! Nom de code : Ğ1. L'annonce officielle a été faite sur le site duniter.org.

Cette monnaie a déjà été adoptée par 73 utilisateurs, et totalise 18.220 unités à ce jour. Et comme il s'agit d'une monnaie libre, quotidiennement cette valeur augmente car tous les membres co-produisent leur part de monnaie chaque jour : ainsi ce midi vers 13h00, je vais moi-même produire 10,00 Ğ1 sur mon porte-monnaie personnel. Comme tous ceux ayant adopté cette monnaie et faisant partie de la toile de confiance.

Décollage de Ğ1, la première crypto-monnaie libre

Jdh : Quand je pense à une crypto-monnaie particulière, il me vient immédiatement à l'esprit son contexte d'utilisation, souvent initiée par ses créateurs et ses premiers utilisateurs.

Qu'en est-il pour le Ğ1 ? Quels sont les cas d'utilisation concrets que vos utilisateurs aujourd'hui en font ou devraient en faire dans un proche futur ?

Cédric : Pour le moment, nous n'en sommes qu'au tout début. La monnaie me semble encore peu utilisée économiquement, bien que l'on commence à voir fleurir les premiers paiements en Ğ1 : on peut noter par exemple le restaurant Nantais Etrillum qui accepte officiellement de servir des repas payés en Ğ1, ou encore le café aux RML9, tout comme s'organise pour ces mêmes RML9 un covoiturage en minibus dont une participation en Ğ1 est acceptée.

Les principales transactions que l'on peut voir passer en blockchain sont surtout des dons, notamment à ceux qui mettent à disposition un nœud Duniter pour faire fonctionner la monnaie, aux développeurs de Duniter et de ses clients (Sakia, Cesium, Silkaj) et plus généralement aux personnes qui s'investissent dans le développement de Ğ1. Mais je ne vérifie pas tout ce qui s'y passe, et il y a peut-être des échanges qui se réalisent sans que je puisse les mesurer !

Il faut dire aussi que nous ne possédons pas encore de place de marché mettant en lien acheteurs et vendeurs de biens et services payables en Ğ1. C'est toutefois en projet, on connaît déjà le nom de ce futur service : ğchange, développé par kimamila, l'auteur de Cesium. ğchange se présentera sous forme de site web et fonctionnera avec des pods à la Diaspora* ou Mastodon. C'est à mon avis le service essentiel qui permettra de faire un véritable bond en avant dans la valorisation et l'utilisation de Ğ1. Au niveau technos, ğchange se base actuellement sur des nœuds ElasticSearch et un front basé sur Ionic 2. Et je crois qu'à ce sujet, toute aide est la bienvenue !

Pendant ce temps, nous nous efforçons d'intégrer des nouveaux membres dans la toile Ğ1 afin qu'ils puissent eux aussi participer à cette économie naissante, et fassent grandir cette toile en certifiant les personnes qu'ils connaissent. Pour donner une idée, nous sommes 73 membres actuellement et nous avons environ 300 personnes dont l'inscription est en attente. Ce week-end du 8-9 avril, entre 3 et 4 membres devraient entrer. Il y a donc du chemin à faire sur ce point !

Jdh : Tu évoques ici Sakia, Cesium et Silkaj. Tu nous as parlé de ce que faisait Duniter mais peux-tu expliquer leurs rôles respectifs de ces autres programmes ?

Cédric : Si Duniter est le cœur du réseau Ğ1, Sakia, Cesium et Silkaj en sont les éléments périphériques permettant de s'y connecter. On parle de client. Pourquoi avoir des clients ? Tout simplement car tout utilisateur n'a pas forcément besoin d'exécuter Duniter sur sa machine, qui suppose d'être connecté en permanence, de télécharger l'intégralité de la blockchain et d'utiliser ses ressources pour vérifier son intégrité et calculer les prochains blocs. Les clients sont en fait des outils dialoguant avec le réseau Duniter (le cœur) pour y réaliser des opérations, comme envoyer et recevoir de la monnaie, rejoindre Ğ1 en tant que membre ou encore certifier ses semblables.

Logo de l’application Cesium, application web cliente pour Duniter

Sakia est le client historique, écrit en python. C'est une application de bureau installable sur la plupart des distributions Linux. Ce client permet de réaliser l'intégralité des opérations du réseau Ğ1 (transactions, toile de confiance). Il permet également une supervision réseau basique.

Cesium est le pendant web de Sakia. C'est-à-dire que cette application a les mêmes fonctions, mais cette fois-ci dans un navigateur. Elle a également la réputation d'être plus simple pour un nouveau venu non-informaticien. Et pour cause, il suffit d'une connexion Internet pour y accéder.

Silkaj est le dernier né de la tribu. C'est un client en ligne de commandes. Jusqu'à il y a peu, il ne permettait que d'explorer le réseau et afficher quelques informations techniques. Mais depuis peu, il est également capable d'effectuer des transactions : on peut donc désormais envoyer et recevoir des Ğ1 en ligne de commandes ! Ce qui peut être très pratique pour des tâches d'automatisation, comme effectuer des paiements réguliers.

Jdh : C'est super, le projet bouge dans tous les sens. Dans tes rêves les plus fous, quel serait l'usage et la place occupée par Ğ1 dans notre société ?

Cédric : Dans mes rêves les plus fous, nous sommes un million d'utilisateurs. Cela peut paraître un « petit rêve pas si fou » et peu en rapport à la population française (67 millions, donc seulement 1 utilisateur sur 67 français), mais quand on regarde le Bitcoin et son impact déjà colossal en 2014 avec une estimation à cent mille utilisateurs, faire dix fois plus, n'est-ce pas déjà prodigieux ? Imaginer qu'un million d'utilisateurs produisent chaque jour sa part de monnaie et soit donc capable de dire lui-même ce qui est valeur ou non à ses yeux à la place du banquier, imaginons que 10% d'entre eux soient des développeurs de logiciels libres, n'aurait-on pas là un formidable tremplin pour leur développement ? De même pour de nombreuses autres valeurs, et au détriment de celles que ces mêmes utilisateurs de monnaie libre ne souhaitent plus développer mais qui le faisaient par besoin ou obligation du fait du monopole des banquiers en monnaie non-libre ?

Logo de Ğ1, la première crypto-monnaie libre

Je ne sais pas quel serait précisément l'usage de la monnaie libre, puisque je ne sais pas ce que souhaitent développer les humains. Nous avons tous notre point de vue sur la question. C'est la raison même d'exister de la monnaie libre, reconnaître qu'on ne sait pas dire ce qui est « production » et ce qui ne l'est pas, étant un point de vue relatif. Je trouve les logiciels libres de grande valeur et les logiciels privateurs d'une moindre valeur. Tout le monde n'est pas d'accord avec ça. Et donc si ces humains pouvaient désormais s'adonner en partie à développer les valeurs qui leurs sont chères, vers quoi nous dirigerions-nous ? On peut en avoir une petite idée en jouant à Ğeconomicus, le jeu de simulation de la monnaie libre sur une durée de 80 ans. Je ne donnerai pas de résultats, je laisse les intéressés aller les trouver ou tout simplement aller jouer à ce jeu. Mais assurément, c'est une perspective qui me plaît et m'apaise profondément.

Et là on peut se dire qu'avec nos 73 petits utilisateurs, on en est loin. Oui mais, nous étions 59 il y a 30 jours, ce qui fait une croissance de 23% en un mois. Si une telle croissance durait ne serait-ce que 3 années, nous aurions déjà le nombre d'utilisateurs que Bitcoin a eu en 5 ans. Alors, est-on si loin de ce doux rêve ? Je ne crois pas !

Jdh : Je te remercie pour cet entretien.

- Entretien réalisé par Carl Chenet pour Le Journal du hacker.

Entretien avec Frank Rousseau, co-fondateur de Cozy Cloud

Rédigé par Carl Chenet - -

Jdh : Bonjour Frank et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Frank : Ah tout de suite une question difficile ! J'ai 33 ans, j'ai toujours aimé bidouillé des sites web et des web apps en dehors de mes études (d'informatique) et de mon boulot.

Je ne me suis mis au dev de logiciel libre sérieusement il y a 5 ans. J'ai commencé par développer un projet de réseau social distribué en Python sur mon temps libre. Ça m'a permis de monter un projet propre avec ma façon de faire. Puis j'ai +enchaîné sur le projet Cozy, cette fois à temps plein, une plateforme pour rendre le serveur personnel simple d'utilisation (basée surNode.js et codée enCoffeeScript).

A côté de ça j'ai toujours beaucoup travaillé sous Linux (Slackware, Debian et Ubuntu) et mon éditeur de prédilection est Vim.

Cozy s'est fait autour d'un projet entrepreneurial. Ce qui m'a permis d'évoluer dans le monde du Logiciel Libre à plein temps depuis maintenant 4 ans. En plus de Cozy j'ai maintenu quelques bibliothèques Node.js que nous avons extraites du projet. C'est une expérience d'autant plus intéressante que je suis passé par étapes, de développeur seul à leader technique d'une équipe de 10 personnes de haut niveau. J'ai du aussi gérer pas mal d'aspects produits et marketing pour structurer le projet et le faire connaitre. Et par dessus tout ça, j'ai vu notre communauté grandir, comme vous le comprenez c'est une sacré aventure !

Jdh : Peux-tu nous en dire un peu plus sur ce premier réseau social distribué que tu as lancé et comment ça a influencé ta vision pour arriver à l'idée de Cozy ?

Frank : Ce réseau social s'appelle Newebe. J'ai commencé à y réfléchir à l'époque de la prise de conscience générale sur le fait que Facebook, de part son architecture, stockait toutes nos conversations. Peu de temps après le réseau social Diaspora* faisait son buzz. Cela semblait être une bonne solution mais je n'étais pas satisfait de leur approche fédérative. Diaspora* permettait d'avoir plusieurs nœuds basés sur du Logiciel Libre plutôt qu'un nœud central basé sur du code propriétaire. C'était un gros progrès mais il y avait toujours un intermédiaire. Même problème avec les approches plus anciennes basées sur XMPP. Aujourd'hui, je suis moins extrême sur la question mais à l'époque je considérais que ça déplaçait le problème sans le résoudre.

Je me suis donc dit qu'il fallait une autre approche. Je suis parti de l'utilisateur en considérant que chaque nœud devait représenter son propriétaire. J'en ai déduit qu'il fallait faire une interface web adossée à une API Rest que chacun héberge chez soi. En faisant communiquer les instances d'API entre elles, on obtiendrait un réseau social complètement distribué. C'était beaucoup plus difficile que prévu à réaliser mais je suis tout de même arrivé à quelque chose qui marche. A ce moment là, Newebe ne gérait que le microblogging. Mais là j'avais envie de permettre d'ajouter d'autres applications sociales qui profiteraient des fonctionnalités de communication de Newebe pour collaborer de manière distribuée.

NB : Voici la spec que je m'étais écrite avant de commencer Newebe.

Ce réseau social n'a pas eu beaucoup de succès et je ne suis donc pas allé au bout du concept. Mais cette expérience m'a donné les prémisses de ce que nous allions faire sur Cozy. Mon expérience de Newebe m'a influencé sur bien des aspects dans Cozy mais voici les principaux qui me viennent à l'esprit :

J'avais remarqué que faire un réseau social demande non seulement de faire basculer l'utilisateur mais aussi tous ses amis. Ce qui est très compliqué avec une approche distribuée / auto-hébergée. Pour Cozy, ce constat nous a conforté dans notre choix de nous focaliser sur des usages persos plutôt que sociaux / collaboratifs. Techniquement c'est plus simple et ça ne demande pas à l'utilisateur de demander à tous ses amis de passer à l'auto-hébergement.

J'avais aussi constaté via l'approche CouchDB que le fichier n'est qu'une représentation de la donnée. Ce n'est donc pas le bon support pour représenter les données de l'utilisateur. C'est pourquoi dans Cozy nous nous sommes concentrés sur les documents JSON comme axe de représentation de la donnée.

Pour les choix de techno, mon expérience de Tornado m'a poussé vers Node. J'avais été convaincu par l'approche de serveur web asynchrone (requête non-bloquantes) de Tornado. Node suivant cette philosophie et étant très bien outillé pour le développment web, nous avons choisi de basculer sur cette techno.

L'utilisation de CouchDB dans Newebe nous a permis de démarrer vite sur Cozy car je connaissais déjà cette base de données. Mais aujourd'hui, j'ai des doutes sur la pertinence de ce choix à cause de son système de vues/requêtes un peu particulier.

Enfin, les single-page applications nous ont motivé à fortement découpler le serveur du client. C'est important car nous avons toujours vu Cozy comme un point de pivot des données de l'utilisateur. Ainsi n'importe quel type de client peut s'y connecter (mobile, CLI, appli desktop, etc.)

Au-delà de ça, avec Newebe, je me suis beaucoup intéressé au life-logging, au quantified-self et aux assistants personnels. Ces univers sont de bonnes sources d'inspiration pour donner une direction à Cozy !

NB : Un lien de réflexions liées à Newebe.

Bref tout ça pour dire que le travail fait sur Newebe m'a beaucoup aidé pour apporter les premières briques de Cozy.

Jdh : Venons-en à Cozy. Comment est né le projet ? Quelles ont été les motivations à l'origine du projet ? Quelle a été ton approche au début du projet et à quel moment as-tu commencé à sentir que cela mènerait loin ?

Frank : Fin 2011, je me retrouve brutalement au chômage avec quelques indemnités. Ça faisait un moment que je voulais monter une boîte et cette situation me le permettait. J'avais lu quelques bouquins sur le sujet et je me mettais donc en veille en commençant à penser à des idées avant de me lancer (je voulais finir avant un projet de bouquin photos auquel j'avais participé). Un soir de décembre, en lisant un post sur le Framablog à propos de la vie privée, je tombe sur un commentaire un peu particulier d'un certain Benjamin qui cherche à monter un projet d'entreprise pour proposer une solution. Un peu hésitant au départ, je me dis que ça tombe plutôt bien et que je ferais mieux de le contacter. Après s'être rencontrés, on se rend compte qu'on est totalement sur la même longueur d'ondes. Rapidement on s'y met. Il avait une vision business alors que j'arrivais avec une vision technique, ça collait bien. On a trouvé un nom au projet, on a fait les premiers protos, on a pris un nom de domaine, monté un site web, on s'est organisé et on a monté la boite.

Au final, ça nous a pris du temps pour se décider sur comment tout ça allait marcher, mais après de nombreux mois (presque un an !), nous voilà avec une société enregistrée au tribunal de commerce, un joli site web et de quoi quoi déployer nos protos de Cozy. Tout ça nous a pris pas mal de temps. Un stagiaire, Lucas, nous avait rejoint pour nous aider sur la partie Sys Admin. On ne le savait pas encore mais il allait devenir notre premier employé.

Forts de ce qu'on avait monté, on a pu convaincre Zoé, Romain et Joseph de nous rejoindre. En stage au début et ensuite, à temps plein. Avec eux ça a boosté. Notre proto était de plus en plus fonctionnel. Ça restait bancal mais c'était utilisable et on voyait bien l'intérêt de la plateforme. On a eu de l'exposition dans plusieurs endroits : LinuxFr, LeWeb, Hacker News, Mozilla WebFWD et un article dans le magazine Wired. On a vu une première communauté internationale se former. Là je pense qu'on a commencé à vraiment y croire. Notre histoire prenait forme et on voyait la plateforme progresser de jour en jour. La tuile qui m'était tombé dessus avec ma boite précédente s'est transformée en belle opportunité de faire progresser le schmilblick du lien entre cloud et vie privée.

Pour ce qui est des motivations, notre but était de permettre aux utilisateurs de service web de profiter d'une plateforme simplifiant l'usage du serveur personnel. Avec ce nouvel outil, un utilisateur récupère ses données dans une base de données, en maîtrise les accès et surtout peut y brancher ses périphériques et autres application lourdes. Ainsi on apporte aux gens un meilleur contrôle de leurs données tout en fluidifiant leur vie numérique. Les outils type "silos" sont pratiques mais comme ils sont cloisonnés, ils ne nous facilitent pas vraiment la vie. C'est le principal problème que Cozy résout.

Pour l'approche, comme tu as pu le comprendre, on a fonctionné en itération avec pour objectif d'avoir quelque chose de fonctionnel le plus tôt possible. Ça a pris du temps au début car il a fallu, entre autres, se mettre à l'admin système sérieusement, maîtriser l'écosystème Node alors qu'il était tout jeune et faire une app web "classique" pour que les gens puissent s'inscrire et demander un Cozy. Enfin il a fallu trouver et assembler diverses technos pour faire marcher le tout sans trop réinventer la roue (le déployeur d'apps Haibu et l'indexeur Whoosh notamment). En plus de ça on travaillait avec La Poste et la FING pour réaliser des prestations qui nous ramenaient des sous. Ça nous a pris pas mal de temps mais en restant sur ce mode tout en augmentant notre équipe (grâce à une belle levée de fonds), nous avons pu continuer jusqu'à aujourd'hui et obtenir une belle plateforme pleinement fonctionnelle !

Jdh : Aujourd'hui, combien êtes-vous à travailler sur Cozy ? Quels sont les axes de développement actuels ? J'ai vu passer une offre en partenariat avec OVH et j'ai trouvé intéressante l'initiative. Quelle est ta vision à moyen terme pour Cozy ?

Frank : Aujourd'hui nous sommes une petite vingtaine toutes professions confondues. En développeurs / admins, on est une petite dizaine accompagnée d'une équipe produit de 3 personnes.

Au niveau des développements, on est en train de finaliser notre client desktop et notre webmail. L'équipe est vraiment efficace et nous avons hâte de voir le résultat. On aura enfin une plateforme proposant tous les services de base, auto-hébergeables et sur laquelle tous nos périphériques peuvent se connecter.

La vision à moyen terme de Cozy est de continuer à consolider tout ça et de construire une offre commerciale sous forme de location de Cozy en ligne puis peut-être sous une forme de box à brancher chez soi. On travaille déjà avec Gandi et OVH pour qu'ils nous aident à construire cette offre. On va aussi mettre l'accent sur l'enrichissement des données duCozy via un système de connecteurs. Ce sont des petits scripts qui vont récupérer les données que vous déposez chez vos différents fournisseurs (factures, santé, banque, etc.). C'est un gros différenciateur de Cozy par rapport aux autres clouds et la communauté aime bien ce concept car elle peut +facilement participer.

On va aussi commencer à voir des grosses boites qui déploient leur compte client sur la plateforme (une app pour gérer ses contrats et intéractions). On voudrait aussi développer des fonctionnalités pair à pair au sein du Cozy. Deux chercheurs y travaillent chez nous, on a hâte de voir ce que ça donne !

Jdh : Les lecteurs du Journal du hacker sont très curieux Peux-tu nous donner quelques détails sur les technologies utilisées pour votre infrastructure afin de développer et faire tourner Cozy ?

Frank : A propos de notre infrastructure d'hébergement, il y a pas mal de choses à dire. Tellement que j'aurais été plus à l'aise que nos admins répondent à cette question à ma place. Mais en gros, ils sont deux, Nicolas et Lucas, pour faire tourner 2500 conteneurs Cozy. Un troisième vient les rejoindre (Aeris, que vous connaissez sans doute) pour les aider. Enfin, Cédric développe des outils maison pour mieux gérer notre infra, mais il a un profil développeur. Pour se synchroniser, ils bossent tous sur un mode Kanban.

Pour le matos, on utilise des gros serveurs OVH appartenant au même rack virtuel. Ça nous permet d'avoir un réseau privé pour ces machines. On les découpe ensuite en conteneurs et on met un joli proxy devant pour gérer la distribution des requêtes en fonctions du nom de domaine.

Niveau technos, l'orchestration se fait via SaltStack et nous déployons des conteneurs OpenVZ (en 2016 on voudrait migrer vers LXC). Nous avons aussi pas mal de sondes pour récupérer des données pour faire de la métrologie via une stack Elastic Search / Logstash / Kibana et une stack InfluxDB / Grafana (selon le type de données).

Pour le monitoring, c'est Shinken qui nous réveille la nuit quand survient un problème. Enfin, les backups sont gérés via une solution maison et notre intégration continue se base sur Jenkins. Pour notre outil interne, on a développé une API via Flask et nos données sont stockées dans une base MongoDB. Cet outil nous permettra bientôt de gérer nos conteneurs de manière +uniforme quelque soit le fournisseur de machines (Gandi ou OVH par exemple).

Les conteneurs Cozy font tourner des process Node.js, une base de données CouchDB (Erlang) et des sondes Beaver et collectd. Le tout tourne sur une Debian 8 minimaliste. Les tests des applications tournent sous Travis et sont consultables publiquement.

A côté de ça, on a pas mal d'images à maintenir (Raspberry Pi, Virtualbox, hébergeurs, etc.) ainsi que notre dépôt Debian, Pour couronner le tout, nous avons un conteneur pour chacun de nos outils traditionnels : site web (Metalsmith), documentation (DocPad), blog (Dotclear), wiki, etc.

Comme vous pouvez le voir nos admins sont super-productifs et savent bien jongler avec les technos ! Et en plus ils s'entendent bien avec nos développeurs. Que demande le peuple ?

Jdh : Merci Frank.

Frank : Merci au Journal du Hacker que je suis toujours avec grand plaisir !

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Entretien avec Tarek Ziadé, engineering manager pour Mozilla Corporation et Pythoniste

Rédigé par Carl Chenet - -

Jdh : Bonjour Tarek et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Tarek : Je suis développeur depuis une quinzaine d'années et je me suis spécialisé dans le langage Python il y a un peu plus de dix ans.

Je me suis passionné pour l'open source et pour Zope en particulier et j'ai lancé un site web autour de cette techno à l'époque. Avec quelques compères du forum de Zopeur, nous avons fondé l'Afpy (Association Python Francophone).

J'ai aussi écrit trois livres sur Python dont un en Anglais.

Je bosse depuis plus de 5 ans pour Mozilla où j'anime une petite équipe qui écrit des services web.

Jdh : Tu viens d'évoquer Zope, que les anciens de la communauté Python connaissent bien. Quand et comment as-tu commencé à coder avec Python ?

Tarek : J'ai découvert Zope et Python à peu près en même temps. C'est en codant des petites fonctions dans l'admin Zope que je me suis mis à Python sérieusement, il y a plus de 10 ans.

Jdh : Et tu as apparemment pris goût à Python ! Je t'ai découvert grâce à ton excellent livre "Programmation Python - syntaxe, conception et optimisation" à l'époque. Peux-tu nous en dire un peu plus sur ce qui t'a amené à passer du statut de développeur à auteur ?

Tarek : C'est simple : je suis devenu fan de Python et j'ai eu envie de le maitriser au maximum.

Et écrire un livre est la meilleure des techniques : il faut bien maitriser chaque sujet pour pouvoir l'expliquer aux autres.

Ça a été un travail intense de 9 mois. J'y ai passé toutes mes soirées :)

Jdh : Lorsque nous nous sommes connus, tu étais très impliqué dans le développement de certains modules de la bibliothèque standard de Python, en particulier je me souviens de Distutils. Qu'en est-il aujourd'hui de ton implication dans le développement de Python ?

Tarek : J'ai beaucoup travaillé sur Disutils effectivement, car le packaging dans Python souffrait de gros problèmes et personne n'avait envie de s'y coller.

Le plus gros travail a été politique : écrire des PEP (Python Enhancement Proposals) pour faire avancer les standards en mettant tout le monde d'accord, puis un peu de code. Je me suis un peu trop impliqué pendant 2 ans sur le sujet et j'ai vécu un "burnout" le jour où mon travail sur un nouvel outil (Disutils2) qui devait être intégré à la bibliothèque standard a été retiré au dernier moment. Je l'ai mal vécu haha.

Tout ce travail a quand même porté ses fruits puisque le packaging s'améliore grandement et il y a pas mal de choses qui sont issues de mon travail. Certaines parties de Disutils2 ont été recyclées dans d'autres projets aussi.

Un conseil: ne tombez pas dans le piège de comparer le packaging de Python avec ceux très récents comme npm (node) ou cabal (haskell) ou même Debian, et de dire que "le packaging est un problème résolu depuis longtemps", Python est un papy de plus de 20 ans et tout le drame du packaging est de pouvoir difficilement faire table rase de l'existant, surtout dans un éco-système où cohabitent des communautés très différentes. Si vous parlez de packaging avec la communauté scientifique ou avec la communauté web, ce sont deux monde tellement différents qu'il est très dur de trouver des solutions universelles et respectueuses de l'existant.

Aujourd'hui je ne suis plus du tout impliqué dans le développement de Python. Ça prend trop de temps et d’énergie, que je préfère garder pour aller courir ou jouer de la trompette. Mon combat dans le code est maintenant à Mozilla :)

Jdh : La fondation Mozilla et ses projets passionnent les membres de notre communauté. Peux-tu un peu nous décrire quels sont tes projets techniques pour la fondation et ta façon de travailler chez Mozilla ? Lors de notre dernière rencontre tu vivais dans un petit village assez isolé des grands centres urbains.

Tarek : Je bosse pour Mozilla Corporation, qui est financée et dirigée à 100% par Mozilla Foundation, et qui a des salariés dans de nombreux pays. La Foundation en a aussi, distinctement de la Corporation.

Quand je suis arrivé il y a plus de 5 ans chez Mozilla, ma mission était simple : j'étais le premier développeur Python de l'équipe "Services" et mon job a consisté à porter Firefox Sync (alors en PHP) sous Python et mettre en place tout l'éco-système Python.

J'étais le seul européen de l'équipe, et je devais faire des réunions parfois à 2 heures du mat'. À l'époque Mozilla Corp. comptait autour de 350 salariés.

Tout a évolué et s'est structuré, et en 2016 on dépasse les 1000 employés avec beaucoup plus de monde en France (environ 45), et je suis maintenant "engineering manager" d'une équipe de Français dispatchés entre Rennes, Barcelone et Montpellier. Moi-même je suis dans un tout petit bled en Bourgogne (175 habitants).

On travaille en ce moment sur Kinto un service de stockage de données avec une API HTTP Json, écrite en Python avec Pyramid, Cornice et Cliquet. Je ne développe plus trop, je passe plus de temps dans des réunions et dans la gestion des projets Mozilla basés sur Kinto, et sur les échanges techniques avec les gens de mon équipe.

Bosser chez Mozilla est assez confortable en termes de moyens à notre disposition : on peut se rencontrer plusieurs fois par an pour faire des "work weeks", disposer de toutes les ressources nécessaires en ligne (serveurs virtuels etc).

Le seul regret de vivre à la campagne finalement est que ma connexion ADSL est mauvaise, ce qui est pénible pour les vidéoconférences.

Jdh : Peux-tu nous détailler un peu plus les projets sur lesquels tu as travaillé et travaille actuellement pour Mozilla ?

Tarek : En 6 ans de temps j'ai eu le temps de bosser sur beaucoup de projets à Mozilla.

Les plus intéressants :

  • Firefox Sync : J'ai réecris le serveur PHP en Python, en utilisant Gevent
  • Circus : Un gestionnaire de processus
  • Cornice : une surcouche de Pyramid pour écrire des web services
  • Loads : Un outil de load testing distribué

Et plus récemment, Kinto, un service de stockage JSON. Je ne développe quasiment pas dedans vu que j'ai changé de casquette (manager) mais je m'occupe de son intégration au sein de Mozilla pour nos différents besoins.

Kinto est maintenant utilisé par Firefox pour la mise à jour de données régulières. L'idée est de réussir à mettre à jour des informations importantes comme les révocations de certificats, sans avoir à attendre que la prochaine version de Firefox sorte.

Jdh : Firefox Sync est utilisé par le grand public et est donc un projet très visible. On a du mal à imaginer l'ampleur de l'investissement derrière. Peux-tu nous parler un peu des gens et de l'infrastructure derrière une fonctionnalité comme celle-ci ?

Tarek : La partie service web en Python est assez anecdotique, au départ j'étais tout seul à coder dessus. C'est quelques milliers de lignes tout au plus.

Le service web en Python, c'est l'arbre qui cache la forêt, 5% du temps de la requête. La difficulté de ce système est surtout liée à la base de données :

  • la maintenance de plusieurs centaines de serveurs MySQL
  • le sharding des utilisateurs sur toutes ces bases
  • la gestion des migrations des utilisateurs etc

Il y a 6 ans nous étions déployés dans des datacenters et il fallait tout gérer nous-mêmes, par exemple le remplacement des disques durs.

Aujourd'hui tout est déployé sur des services clouds comme AWS. Et c'est le cas pour Kinto : des web heads à la demande et Postgres RDS.

En terme de tests, mon équipe est fière d'avoir un coverage de 100% partout, et nous avons des batteries de tests d’intégration qui se lancent sur Travis-CI

Nous avons un environnement de staging sur lequel nous déployons les nouvelles versions, et une équipe de QA qui se charge d'effectuer la recette le tout avant de nous donner le feu vert. L'équipe de Ops utilise Puppet pour tous nos déploiements.

Jdh : Kinto et Circus ont chacun plus de 1000 étoiles Github, avec un nombre de rapports de bugs importants, ce qui en fait des projets assez populaires. Comment se partage la journée type d'un développeur Mozilla ? Y'a-t-il une répartition du travail entre ce qui est fait pour la communauté directement et pour l'infrastructure Mozilla ? Les deux sont-ils confondus en permanence ?

Tarek : C'est une excellente question. Mon job principal justement, en tant que engineering manager, est de faire converger les besoins de Mozilla avec l'envie de développer des fonctionnalités qui sont utiles à une communauté plus large.

Le principe de base est que chaque grosse fonctionnalité que l'on ajoute dans les projets doit émaner d'un besoin réel dans l'un des projets internes - sans pour autant rendre le projet spécifique à Mozilla.

La signature des données dans Kinto est un bon exemple : nous devons signer toutes les données qui sont envoyées à Firefox pour éviter au cas où notre serveur Kinto serait piraté de servir des données corrompues. Ce serait par exemple la catastrophe pour les certificats SSL.

Cette fonctionnalité a été créée sous forme de plugin optionnel en se basant sur des standards ouverts et un système de configuration complet. En d'autres termes, on peut plugger cette option sur nos serveurs à Mozilla sans l'imposer aux autres utilisateurs de Kinto, mais si une autre organisation veut plugger le système de signature, elle pourra le faire !

L'équipe passe bien sûr un peu de temps sur des fonctionnalités 100% communautaires, qui ne sont pas utilisées à Mozilla - mais ce n'est pas la priorité - même si ce n'est jamais du temps perdu.

Le travail sur les bugfixes et push requests (PR) remontés par la communauté quant à lui, est en général fait rapidement : c'est un cadeau précieux qui nous est fait et il est important de ne pas laisser traîner ce travail - ne serait-ce que par respect pour la personne qui a passé du temps dessus.

Enfin, certains projets peuvent à un certain moment être moins utilisés chez nous, et peuvent continuer à vivre. Circus par exemple est moins utilisé qu'avant, et le projet est maintenu par des gens comme Yannick Péroux qui ne bosse pas à Mozilla, c'est génial ! C'est pour moi un exemple de réussite du modèle open source.

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Entretien avec Dimitri Fontaine, développeur PostgreSQL

Rédigé par Carl Chenet - -

Jdh : Bonjour Dimitri et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Dimitri : Bonjour Carl, merci de me proposer de réaliser ensemble cette interview, cela flatte mon égo :) Je travaille aujourd'hui en tant qu'Architecte Logiciel et Expert PostgreSQL, projet auquel j'ai contribué et suis reconnu en tant que PostgreSQL Major Contributor. J'ai contribué en particulier aux notions d'Extension et d'Event Trigger pour PostgreSQL.

Mon outil de travail principal est Emacs, dont la gestion des modules complémentaires laissait à désirer il y a quelques années. J'avais alors retroussé les manches et développé el-get, encore beaucoup utilisé aujourd'hui. Ce projet bénéficie maintenant d'une équipe de mainteneurs actifs, ce dont je suis très content !

Après avoir découvert le lisp avec Emacs Lisp, je me suis naturellement intéressé à Common Lisp… et c'est aujourd'hui mon langage de programmation préféré, ou secondaire dirait James Hague. Et comme le projet pgloader avait besoin d'être revu complètement, je l'ai réécrit en Common Lisp. C'est le projet libre auquel j'accorde aujourd'hui toute mon attention, et j'ai eu beaucoup de retours d'utilisateurs ayant migrés des bases complètes vers PostgreSQL en une seule commande.

Jdh : Commençons par ta participation au projet PostgreSQL. Peux-tu nous dire comment tu en es venu à l'utiliser et nous décrire rapidement ton parcours de, j'imagine, simple contributeur à PostgreSQL Major Contributor ?

Dimitri :Dans le cadre de mes études (IUT Génie Informatique puis École d'Ingénieur, l'ISTY, dépendante de l'université de Versailles) nous avions des cours de base de données relationnelle. À l'école rien n'était installé pour les travaux pratiques et j'ai donc porté la demande auprès de notre administrateur système, et nous avons fini par installer PostgreSQL.

J'ai alors découvert un projet facile à utiliser et dont la documentation complète permet de comprendre le fonctionnement du produit dans son intégralité. Et surtout, chaque commande présentée dans la doc fonctionne exactement comme elle est présentée. C'est reposant ;)

Plus tard, j'ai créé avec des copains une petite entreprise de services en logiciel libre, très orientée Linux et dont le nom intégrait une référence relativement subtile au site d'information des libristes français le plus visité de l'époque… saurez-vous retrouver le slogan qui a inspiré le nom « Da Linux Boite », ainsi que le vrai nom de l'entreprise (toujours en activité) ?

Rapidement, le marché principal sur lequel nous intervenions avec succès étant PostgreSQL, nous avons adapté notre organisation et notre offre commerciale afin de nous concentrer sur cette technologie, ses usages et ses difficultés.

Cette expérience m'a permis de travailler ensuite en tant que DBA (DataBase Architecte plutôt qu'Administrateur, PostgreSQL permettant d'aller beaucoup plus loin que les bases de données relationnelles telles qu'elles sont habituellement envisagées). Dans ce rôle de DBA avancé, j'ai eu l'occasion de mettre au point une extension dédiée au métier d'opérateur téléphonique, comprenant un type de données avec support d'indexation spécifique.

Ce développement m'a permis de découvrir les API et outillages internes de PostgreSQL, et de commencer à lire le code de mon SGBDR préféré. Ce projet a également été l'occasion de comprendre l'étendue du support apporté sur le canal IRC #postgresql sur freenode, où j'ai été accompagné et conseillé dans mes découvertes.

Du coup en parallèle au développement de l'extension prefix et de mon apprentissage approfondit des aspects internes de PostgreSQL (le produit, le projet et la communauté), je participe beaucoup aux listes officielles où je propose mon avis sur tous les sujets qui me plaisent, c'est à dire presque tout ce qui s'y passe… en m'efforçant de toujours rester constructif et faire avancer la situation.

La suite est une histoire habituelle de l'Open Source : la communauté est accueillante, la documentation pourrait être améliorée et c'est le premier patch. Ma première contribution à PostgreSQL est facilement visible encore aujourd'hui, il suffit de comparer la page dans la version 8.3 avec celle de la version 8.4.

Le plaisir d'avoir pu contribuer à un projet aussi reconnu que PostgreSQL m'a donné la motivation nécessaire à passer à la vitesse supérieure. S'il était déjà facile de réaliser une extension incluant un type de données et son indexation spécifique, la restauration des sauvegardes de bases utilisant les extensions était… à revoir. Je m'y attelais et contribuais les commandes CREATE|DROP|ALTER EXTENSION ; cela constitue ma première contribution au code (en C) de PostgreSQL.

Pour le bénéfice des lecteurs de cette interview, je me permettrais de conseiller un projet moins ambitieux dans le cadre d'une première contribution : ce projet là a duré plus de 2 ans et demi et n'a pu aboutir que grâce à ma participation aux Developer Meeting à Ottawa. Sans la rencontre en personne avec les développeurs, les chances de succès d'une telle entreprise auraient été nulles. L'appui sérieux de mon employeur de l'époque (Hi-Media, merci Franck !) a été fondamental.

La meilleure façon de commencer à contribuer à un logiciel Open Source reste la correction de bugs. La mise au point du premier correctif peut prendre plusieurs semaines, ou plusieurs mois, car il est nécessaire de se familiariser avec le code, les APIs, les usages, l'environnement de tests, la documentation, les outils de communication de la communauté du projet (des mailing-listes pour PostgreSQL, une Pull Request consiste à envoyer un patch obtenu avec la commande diff en pièce jointe à son mail dans lequel on décrit le travail réalisé). La mise au point du correctif suivant est en général beaucoup plus rapide, compter quelques heures ou quelques jours. Et si l'on est régulier dans la correction de bugs, on est rapidement intégré et apprécié dans le projet !

Et pour terminer de répondre à la question, le projet PostgreSQL est assez bien organisé, jusque dans la reconnaissance de ses contributeurs. Après 2 ans et demi et 31 versions du patch pour la gestion intégrée des extensions, j'ai donc été reconnu PostgreSQL Major Contributor, ce qui est clairement visible sur la page de référence de la communauté.

Jdh : Peux-tu nous en dire un peu plus sur pgloader, un projet qui approche les 700 étoiles sur ton compte GitHub et qui semble avoir une histoire mouvementée (TCL, puis Python puis Common Lisp si je me réfère au README du projet) et ton rôle dans ce projet ?

Dimitri : En 2005, si je me souviens bien, nous avions un projet de migration d'INFORMIX à PostgreSQL. Il était assez facile d'extraire les données de la base source sous un format relativement proche du CSV, mais très facétieux, et l'outil de référence de chargement de CSV facétieux à l'époque était déjà pgloader, en TCL et peu maintenu.

Après avoir tenté de modifier le code TCL pour de la gestion d'encoding et de chaînes binaires, j'ai préféré reprendre le code (très simple à l'époque, il ne gérait que la reprise sur erreur autour de COPY) pour lui ajouter les options avancées de lecture du format improbable que nous avions à charger, et à l'époque Python a été mon choix.

Le format de configuration de pgloader était alors un .INI dont nous avons assez rapidement atteint les limites. J'ai voulu alors implémenter une configuration avancée avec une grammaire propre, et je me suis heurté de plein fouet à l'incompatibilité de certaines libs python entre les versions 2 et 3 du langage.

Dans la même période, pgloader montrait des faiblesses en terme de performances, et personnellement j'avais découvert Emacs Lisp et réalisé un projet conséquent dans le langage, je voulais investiguer Common Lisp.

Après avoir joué un peu avec Common Lisp sur d'autres projets annexes, convaincu par son mode de développement interactif et la modernité des outils proposés par le langage, j'ai développé un prototype du nouveau pgloader lors d'une migration de MySQL vers PostgreSQL chez un client.

Le pgloader nouveau était alors un projet en cours, et aujourd'hui nous avons de nombreux utilisateurs qui migrent leurs données en une ligne de commande, ou bien importent chaque nuit des quantités de données importantes avec reprise sur erreur automatique.

L'impact principal du choix de Common Lisp réside dans la capacité à développer une nouvelle fonctionnalité, entreprendre un refactoring avancé du code ou bien fixer un bug dans un temps record. Étant donné que pgloader est un projet que je fais vivre sur mon temps libre, pouvoir faire en 2h un soir ce qui me prenait autrefois toutes mes soirées de la semaine est un avantage indéniable !

Au niveau de mon rôle dans le projet, aujourd'hui je suis seul à m'occuper de tout. J'aimerais réussir à construire une équipe de développement et de maintenance comme j'ai pu le faire avec el-get par exemple, et je pense que pgloader est maintenant assez mûr pour cela.

Jdh : Tu me tends une perche que je vais m'empresser de saisir. Tu es également le créateur du projet el-get, qui est, sauf erreur de ma part, un outil pour installer simplement des extensions ou des scripts externes pour Emacs. Peux-tu m'en dire un peu plus sur ton utilisation d'Emacs et comment tu en es venu à écrire cet outil ?

Dimitri : À l'époque où j'ai démarré el-get, mon utilisation d'Emacs ressemblait déjà beaucoup à celle d'aujourd'hui : écriture de code et de documentation, shells interactifs avec M-x shell, emails avec gnus, IRC avec rcirc, le tout avec escreen afin de ne pas perdre la tête.

Ma configuration est en fait une personnalisation avancée de l'outil, avec par exemple des raccourcis me permettant d'adapter le visuel (taille et emplacement des fenêtres, disposition automatique pour IRC en fonction de la taille de l'écran, et plus de modifications aux fonctions de base proposées par Emacs que je ne puis m'en souvenir).

On en est au point où j'ai plus de 5000 lignes de code personnel chargé à chaque lancement d'Emacs (environ une fois par mois), et où je maintiens une configuration minimale (de 150 lignes) : je ne sais plus utiliser Emacs sans quelques changements clés.

Lorsque je commence el-get, il n'existe pas encore de solution de packaging intégrée à Emacs et il faut trouver et maintenir des scripts Emacs Lisp plus ou moins maintenus, souvent sur Emacs Wiki, et les gérer et les distribuer soi-même. L'idée de fond était de pouvoir maintenir une configuration déclarative d'une part, et un jeu de « recettes » faciles à échanger d'autre part.

Le projet a bien marché, si on utilise à nouveau la mesure des stars de GitHub on est à plus de 1200 aujourd'hui, et surtout, le projet est maintenu par une équipe et je ne fais plus grand chose : c'est le plus beau succès de l'Open Source, devenir simple utilisateur de son propre projet.

Jdh : Pour revenir à PostgreSQL et sauf erreur de ma part, tu es le président de la société Second Quadrant France, qui fournit du service autour de PostgreSQL. En tant qu'entrepreneur du Libre, je suis intéressé par ce modèle. Peux-tu nous détailler un peu l'histoire de cette société et quelles sont ses activités aujourd'hui ?

Dimitri : Apporter les valeurs du logiciel libre aux entreprises est quelque chose d'important pour moi, et créer une société de service et d'expertise PostgreSQL s'inscrit pour moi parfaitement dans cette ligne.

2ndQuadrant a été créée il y a environ 15 ans et emploie aujourd'hui un nombre très importants de contributeurs PostgreSQL. L'idée étant que le seul moyen d'apporter de l'expertise sur un logiciel libre est de participer à son développement. Il s'agit bien sûr de proposer des améliorations (correctifs, nouvelles fonctionnalités, etc) mais aussi de s'engager dans le processus de développement (revue de code, participation aux discussions de conception et de choix des fonctionnalités sur lesquelles travailler, etc.).

J'ai eu la chance de pouvoir établir 2ndQuadrant en France en créant l'entreprise avec mon associé Cédric Villemain. Aujourd'hui cependant ma situation personnelle m'a aiguillé vers un nouveau rôle, et je laisse 2ndQuadrant aux soins compétents et éclairés de Cédric.

Les activités de 2ndQuadrant sont toutes centrées autour de la notion de service et d'expertise PostgreSQL et couvrent toutes les étapes de l'utilisation de la solution de traitement de données préférée de tous ses utilisateurs : formation, conception, optimisation, gestion de la production (outils, méthodes, processus, interventions en cas d'incidents), support 24×7, accompagnement, développement à façon, etc.

Vous pouvez retrouver l'ensemble de nos services sur le site de 2ndquadrant.

Pour illustrer le modèle de 2ndQuadrant, prenons l'exemple du support : il est réalisé par des contributeurs PostgreSQL et nous nous engageons à corriger nous-mêmes les avaries logicielles rencontrées par nos clients. Nous nous y engageons car nous disposons du savoir faire requis, simplement parce que les équipes de 2ndQuadrant sont distribuées dans plus de 15 pays couvrant l'ensemble des fuseaux horaires et sont constituées de contributeurs PostgreSQL.

Cela permet en outre aux contributeurs PostgreSQL de 2ndQuadrant de mieux comprendre les besoins des utilisateurs et de les adresser de manière précise et efficace en développant les fonctionnalités les plus utiles dans chaque nouvelle version de PostgreSQL. On peut ainsi parler de cercle vertueux.

C'est le modèle le plus classique de service en logiciel libre, et pour approfondir le sujet je recommande la lecture des livrets bleus édités par le groupe Systematic. Les livrets sont disponibles en ligne aux liens suivants (format PDF disponible gratuitement) ici et .

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Classé dans : Entretien - Mots clés : aucun

Entretien avec Raphaël Hertzog, développeur Debian

Rédigé par Cascador - -

Jdh : Bonjour Raphaël et merci de participer à cet entretien pour le Journal du hacker. Pour nos lecteurs qui ne te connaissent pas, peux-tu te présenter rapidement ?

Raphaël : Je m'appelle Raphaël Hertzog, j'ai 36 ans, je suis marié et j'ai deux garçons (de 2 et 5 ans). Je vis près de Saint-Étienne (à Sorbiers) et j'y travaille aussi puisque je gère ma société (Freexian SARL) depuis chez moi et que l'ensemble de mes missions s'effectuent en télé-travail. Comme je suis très sédentaire, je pratique le badminton à un bon niveau pour entretenir ma forme physique.

Je suis développeur Debian depuis 1997 (ça fait 18 ans, soit la moitié de ma vie !) et j'ai déjà touché à plein de choses au sein du projet... des paquets importants (comme debian-cd, developers-reference, dpkg, python-django), l'administration de certains services (alioth.debian.org), la présidence de Debian France, l'organisation de Debian LTS, …

Mais ce qui m'attire le plus c'est de travailler sur l'infrastructure qui permet à tous les contributeurs d'être plus efficace et de faire un travail de meilleure qualité. Historiquement c'est l'équipe d'Assurance Qualité qui a cristallisé ce genre de projets et c'est au sein de cette équipe que j'ai créé le Package Tracking System et que je maintiens maintenant son successeur, le Debian Package Tracker (une réécriture en Django initiée lors d'un Google Summer of Code).

Accessoirement, je suis également l'auteur du Cahier de l'Admin Debian qui a donné naissance au Debian Administrator's Handbook (Roland Mas est devenu co-auteur avec moi au fil des éditions).

Jdh : C'est en effet l'infrastructure Debian qui assure à tous les contributeurs de ce projet de bonnes bases pour contribuer. Peux-tu nous donner quelques informations sur les efforts entrepris récemment dans ce domaine, les nouveautés déjà disponibles et peut-être celles à venir ?

Raphaël : Ben justement je n'ai pas l'impression qu'on ait fait beaucoup de progrès récemment sur ces thématiques. On peut tout de même citer sources.debian.net qui permet de naviguer facilement dans les sources des paquets Debian, de fournir un lien vers une ligne précise de code, ou vers un patch que Debian applique. Associée à l'extension Firefox/Chromium de Raphaël Geissert, on peut facilement créer un patch sur n'importe quel logiciel empaqueté dans Debian.

Il y a aussi le Debian Maintainer Dashboard qui a été mis en place en s'appuyant sur UDD (Ultimate Debian Database). Mais il fait doublon avec le DDPO (Debian Developer's Package Overview).

Enfin, je citerai volontiers dgit, car l'idée d'avoir une infrastructure centralisée permettant de gérer des paquets Debian simplement avec git est plutôt plaisante. Mais j'ai peur que le projet ne soit voué à l'échec car le projet souffre de limitations importantes : aucun historique n'est disponible sur les paquets, même lorsque le mainteneur utilise déjà git avec le paquet.

En ce qui concerne le futur et n'étant pas devin, je peux simplement donner quelques projets que j'aimerai voir aboutir et sur lesquels je vais sûrement essayer de travailler :

  • Modifier le Package Tracker pour gérer qui est responsable de quoi sur chaque paquet. Il s'agit de remplacer le concept un peu binaire qui veut que soit le paquet a un mainteneur et dans ce cas on suppose qu'il gère tout et que tout va bien, soit le paquet n'a pas de mainteneur et dans ce cas il est abandonné et rien ne va plus.
  • Dans la pratique on a souvent des mainteneurs qui ont besoin du paquet en dépendance d'un paquet qu'ils utilisent et qui vont corriger juste les bogues critiques mais qui laisseraient volontiers le paquet à un mainteneur plus intéressé. Ou alors on a des mainteneurs enregistrés mais qui en fait ne sont plus actifs et le paquet est négligé...

    Et puis on a de plus en plus d'utilisateurs externes qui dépendent de certains paquets dans Debian qui doivent pouvoir les surveiller pour s'assurer qu'ils ne seront pas supprimés dans la prochaine version (ce qui arrive de plus en plus souvent avec la politique de suppression automatique lorsqu'un bogue critique n'est pas corrigé sous 30 jours).

  • Étendre le Package Tracker pour qu'il intègre toutes les fonctionnalités de suivi / coordination qui existent actuellement dans divers services séparés : suivi par contributeur (cf DDPO/DMD déjà cité), suivi par équipe (cf Package Entropy Tracker), coordination de transitions (cf transition trackers de la Release Team)
  • Rationaliser le flux d'informations à destination des mainteneurs. J'avais déjà formalisé les objectifs à atteindre dans le DEP-2 rédigé il y a plus de 4 ans...

Jdh : Tu es au centre de l'initiative Debian LTS, qui fournit un support de longue durée aux différentes versions stables de Debian. Peux-tu nous en dire un peu plus, sur par exemple l'origine du projet, les moyens mis en œuvre, les avancées du projet et ses objectifs ?

Raphaël : Moi j'ai suivi cela de très près et lorsque le projet a été lancé et que quelques propositions d'aides financières ont été émises j'ai immédiatement proposé aux autres contributeurs intéressés par être payés pour travailler sur Squeeze LTS de s'unir derrière une offre unique que l'on pourrait mettre en avant.

C'est ainsi qu'est née l'offre Debian LTS de Freexian. Et à ce jour l'essentiel des contributions à Debian LTS proviennent de contributeurs financés par les sponsors gérés par Freexian. J'ai fait quelques statistiques à ce sujet que j'ai présenté lors de la DebConf (diapos, vidéo).

Personnellement j'estime que c'est un succès, mais un succès modeste tout de même, il nous a fallu plus d'un an pour arriver à financer l'équivalent d'un mi-temps. Quand on sait les moyens financiers des grosses entreprises, on se dit qu'on peut faire bien mieux. Et j'espère effectivement qu'on va réussir à convaincre d'autres entreprises pour pérenniser le projet et se donner des marges de manœuvre que l'on n'a pas encore.

D'ici quelques mois nous allons passer à Debian 7 Wheezy LTS parce que Debian 6 arrivera au terme des 5 ans de support et nous allons essayer d'avoir moins de restrictions en terme de paquets supportés (notamment sur les technologies de virtualisation)... mais il faudra des moyens supplémentaires si l'on ne veut pas que d'autres paquets en pâtissent à terme.

L'objectif de Debian LTS est simple : supporter l'ensemble des paquets Debian pendant 5 ans (sur les architectures où il y a des utilisateurs qui cherchent une version LTS). Mais les moyens d'y arriver sont multiples, d'un côté il faut travailler au jour le jour en corrigeant les CVE sur la version courante, et de l'autre il serait bon de faire un travail en amont pour s'assurer que les logiciels intégrés à Debian 9 Stretch puissent être maintenus pendant 5 ans supplémentaires ! Mon objectif est bien d'arriver à une situation où nous avons assez de ressources pour pouvoir avoir un impact sur les versions en développement et pas seulement sur la version LTS actuelle.

Au delà, j'aimerai que LTS soit une porte d'entrée pour que les entreprises prennent conscience de l'importance de leur implication et qu'ensuite elles contribuent non seulement à LTS mais aussi à d'autres projets Debian qui leur seront bénéfiques à plus long terme.

Jdh : Passons maintenant à un sujet qui passionne les utilisateurs du Logiciel Libre : les rapports Debian-Ubuntu. Toi qui es au cœur du projet Debian depuis des années, peux-tu nous retracer rapidement l'évolution de ces rapports et l'état actuel des interactions entre les deux projets ?

Raphaël : Je ne crois pas que cela soit encore un sujet si passionnant. Il y a eu des tensions au début lorsque Canonical avait embauché un grand nombre de développeurs Debian et qu'ils n'avaient pas les moyens de contribuer en retour à Debian. De nos jours, la communauté Ubuntu est plus large que juste les employés Canonical et les relations sont bien meilleures. De nombreux contributeurs Debian sont aussi des (anciens) contributeurs Ubuntu.

Le plus gros regret que j'ai c'est que Canonical n'ait jamais fait l'effort d'essayer d'intégrer ses développements les plus importants dans Debian, comme Unity par exemple.

Jdh : Tu es connu du grand public pour ton livre "The Debian Administrator’s Handbook" en anglais ou "Cahier de l'admin Debian" en français qu'on aime beaucoup. On trouve également géniales les initiatives que tu as lancées pour libérer les différentes versions. Peux-tu nous parler dans un premier temps de ces initiatives de libération, puis dans un second temps du processus de production du livre en lui-même tel qu'il est aujourd'hui (auto-édition, revue "communautaire", etc) ?

Raphaël : Le livre français avait été écrit pour le compte des éditions Eyrolles et c'est donc eux qui contrôlaient les droits sur le livre. N'ayant jamais réussi à en faire publier une traduction anglaise, Eyrolles a accepté de nous rendre (à moi et Roland) les droits sur une éventuelle traduction anglaise. La première campagne de financement visait simplement à nous donner les moyens de faire ce travail de traduction, avec un palier bonus où la traduction était en plus publiée sous licence libre.

Une fois cet objectif atteint, il restait le livre français sous licence propriétaire alors que le livre anglais était libre. Il fallait corriger cela et cela nécessitait de renégocier avec Eyrolles et de les convaincre que libérer le livre français était la bonne solution. On a profité d'une nouvelle édition à venir pour imaginer un plan gagnant-gagnant : une nouvelle campagne de libération permettait à la fois à Eyrolles d'écouler son stock de livre de l'édition précédente, de financer les frais d'édition de la prochaine édition et de financer une partie du travail des auteurs. Ainsi même si le livre ne se vendait pas (parce qu'il était libre), Eyrolles ne perdrait pas (trop) d'argent.

Au final, le livre français continue de se vendre, même si les chiffres sont plutôt faibles (moins d'un millier d'exemplaires par an).

D'un point de vue plus technique, le livre est rédigé en DocBook XML, il est maintenu dans un dépôt Git comme tout projet libre qui se respecte, les traductions sont gérées avec Publican qui génère des fichiers .po (et les traducteurs mal à l'aise avec les fichiers .po peuvent utiliser Weblate). Le PDF du livre papier est généré avec dblatex et une feuille de style LaTeX personnalisée. Il est imprimé à la demande par Lulu.com pour la version anglaise tandis que la version française est toujours éditée par Eyrolles.

Il se trouve justement que je passe pas mal de temps sur mon livre ces derniers temps car nous sommes en train de finaliser la version Jessie (Debian 8) du livre. J'invite ceux qui veulent être prévenus de la sortie de mon livre à s'abonner à ma newsletter (soit en anglais, soit en français). Et vous pouvez aussi déjà en profiter en ligne bien que la traduction ne soit pas terminée... et nous signaler les éventuelles coquilles avant sa publication !

- Entretien réalisé par Carl Chenet pour le Journal du hacker.

Fil Rss des articles de cette catégorie