Je reprends cette année mon rituel qui consiste à partager ce que j'ai appris en participant à un projet libre. J'ai sauté l'année dernière faute d'inspiration. Pour cette fois-ci, je voudrais discuter de comment j'ai encore passé deux ans à développer du logiciel libre dans un cadre professionnelle (autrement dit, payé pour ça). Dans un deuxième temps je vais sortir du cadre du bilan pour partager mes doutes et mes craintes sur la situation actuelle du logiciel libre. Et oui il y aura un peu de pessimisme dans ce bilan pour changer. Je terminerais sur les petits projets que j'ai démarrés pour le fun et sur des idées que j'aimerais développer.

Bilans précédents : 1, 2, 3, 4, 5, 6

Ce que j'ai fait cette année

J'ai principalement travaillé sur le projet d'entreprise CGWire. Son activité consiste à fournir des logiciels pour faciliter la production de films d'animation. Pour commencer nous développons un outil de gestion de production. L'idée est de distribuer des solutions communes et libres à cette industrie. De cette manière ils pourront se concentrer au démarrage sur l'artistique plutôt que sur de la technique.

En effet aujourd'hui, seules des solutions propriétaires complexes et coûteuses existent. Résultat chaque studio a tendance à les utiliser ou développer en interne quelque chose de similaire. D'où l'idée de leur proposer un outil simple et efficace sous licence libre sur lequel ils peuvent se baser avant de se lancer dans des grands développements ou investissements.

Au delà du code publié, ce projet a été l'occasion de monter une communauté. J'ai pu réunir ainsi dans un groupe de discussion Slack une centaine de personnes spécialisées dans les pipelines de fabrications de films d'animation. Le point de départ qui m'a permis de monter ce groupe de discussion est clairement le logiciel libre. En effet beaucoup sont venus pour parler technique et code. C'est un outil qui se prête bien à la rencontre des gens et à l'échange de connaissances.

Au niveau de mon setup de développement, j'ai remis à jour ma liste de plugins vim, mais en dehors de ça je n'ai pas changé grand chose. J'utilise toujours terminator comme terminal et zsh comme shell. Pour le clavier, je me suis habitué à la disposition bépo. J'ai retrouvé une vitesse de frappe normale (55 mots par minutes). Par contre, j'ai du mal à taper en azerty désormais. Ce qui m'inquiète parfois.
Dans le mème style, je suis aussi passé à une souris verticale. La prise en main se fait assez vite et on sent moins de tension dans le bras rapidement.

Du point de vue technos, j'ai beaucoup fait de Python (Flask en framework) pour développer l'API du logiciel de CGWire. J'ai aussi fait pas mal de Javascript (Vue en framework). J'ai développé seul avec des mises en production fréquentes. J'ai un peu utilisé Ansible pour les déploiements. J'ai aussi eu l'occasion de jouer avec la CI de Gitlab qui m'a bien plu.

A propos du code, côté serveur j'ai fait les choses à peu près bien pour le temps imparti et mes conditions de code (le montage de la société en parallèle prend pas mal d'énergie). L'approche TDD était salvatrice pour le développement d'une API. Je ne me vois plus en développer une sérieusement sans cette pratique.
Pour le frontend, j'ai écrit peu de tests et je le regrette déjà. J'ai toujours du mal à mettre un bon environnement de tests pour le frontend, j'ai donc procrastiné dessus et aujourd'hui j'ai du retard.

En veille technologique, j'ai rejoué avec Go que je vois de plus en plus comme le Python du compilé. J'ai découvert Rust dont le compilateur m'a bien plu. Il pousse notamment à bien penser l'utilisation de ses variables. J'ai pu goûter à Ruby on Rails. C'est propre mais ça ne m'a pas emballé (rien de rationnel derrière cette impression). Aujourd'hui je regarde Elixir et son framework Phoenix. Il est encore trop tôt pour avoir un avis mais je suis attiré par l'aspect fonctionnel et compilé.

Voilà pour mes activités. Maintenant enchaînons sur un constat que j'ai fait avec cette nouvelle expérience entrepreneuriale et qui pourra vous être utile !

Photo par Hexagram

La tension du marché comme pouvoir de négociation sur l'ouverture des sources

Cela va donc bientôt faire 7 ans que je fais du logicel libre à temps plein. Lorsque je travaillais pour Cozy Cloud, cela était possible grâce à des financements d'organismes dédiés (Pôle Emploi, BPI et fonds d'investissement) et de nos clients. Avec CGWire, l'ensemble des développements ont été financés par des studios utilisateurs. C'est une évolution intéressante car elle rend ma démarche plus viable à long terme.

Dans le secteur de l'animation, il est difficile de trouver des développeurs. Les problématiques attirent moins (tous les développements se font à petite échelle) et les studios n'ont pas les moyens de s'aligner sur les salaires des entreprises web. Grâce à cette situation, j'ai pu négocier avec eux de financer la solution que je développais à condition de la publier sous licence AGPL. De cette manière, ils profitent de mon expertise technique (un diplôme universitaire et 13 ans d'expérience) et peuvent garder la main sur la solution si besoin. En échange je peux faire avancer le projet. Comme plusieurs studios s'y mettent, cela favorise aussi la collaboration. De cette manière, j'ai réussi à faire en sorte que cinq studios contribuent sous forme de sponsoring.

Tout ça pour dire que cela m'a amené à une idée. Comme, aujourd'hui il est difficile de recruter un bon développeur, les salaires montent en conséquence. Or beaucoup de développeurs ne font pas du salaire leur priorité. Plutôt que de demander un salaire élevé, ne serait-il pas intéressant de négocier que le logiciel développé soit publié sous licence libre sur une plateforme comme Github ou Gitlab ? Ou même carrément d'exiger l'ouverture du code sans autre concession sur le salaire ? Est-ce que cela pourrait contribuer à faire avancer la quantité de code libre disponible ? à faire bouger les lignes ? je suis curieux d'avoir votre avis.

L'autre effet intéressant est ce que cela inspire. D'autres employés de studios ont publié du code. Déjà trois studios ont proposé des projets libres : Kabaret un framework d'application Qt métier, JeanpaulStart un lanceur d'applications / batches, ou ThonSide une console Python pour Qt.

En résumé, les développeurs sont en position de force sur les employeurs. N'est-ce pas là un levier à exploiter pour produire plus de sources libres ? N'est-ce pas le temps d'initier d'autres industries au code ouvert ?

Photo par Rubén P.

Les désillusions

J'ai fait quelques constats qui m'ennuient alors je les partage ici. Je n'aime pas parler d'un problème sans proposer une piste de solution mais pour cette année je fais exception.

1. La structure pour supporter un projet libre.

Il semble difficile de faire un logiciel libre dominant sans entreprise derrière. On a quelques exceptions comme Krita, Mastodon ou Firefox. Mais globalement j'ai l'impression que les logiciels libres qui deviennent important ont une entreprise derrière pour les pousser. Est-il possible dans le contexte actuel de monter un projet utilisé massivement sans une structure à but lucratif ?

2. Les critiques de l'auto-hébergement et de la décentralisation en général.

J'ai vu de nombreux tweets passés disant que s'auto-héberger c'était mal et que c'était criminel de le conseiller. Je comprends que cette pratique a ses limites et qu'il faut en parler, mais j'ai l'impression que ça tourne à l'auto-flagellation. J'ai vu un phénomène similaire sur la chaîne de blocs ou plus récemment sur le projet SOLID. Pourtant ces technos ont le potentiel de nous sortir du tout cloud.

Même si l'un pose des soucis de sécurité, que l'autre pose des problèmes écologiques/spéculatifs, je ne suis pas sûr que ça soit une bonne idée de les fustiger et de s'arrêter là à cause de ces défauts. En effet on ne croule pas sous les alternatives. Si aux début du web on s'en était arrêté à ses limites, on n'aurait rien aujourd'hui.

3. l'avènement du cloud.

Il faut bien l'admettre, le cloud (autrement dit les fermes de serveurs détenues par quelques groupes privés que tout le monde loue pour déployer ses applications et stocker ses données) devient le standard pour faire un nouvel outil. A l'usage c'est bien pratique et je suis le premier à en abuser. Mais ça pose plusieurs soucis :

Toutes les données personnelles ou industrielles sont captées par quelques groupes privés (par des groupes non élus et sur lequel nous n'avons pas d'emprise)
La quasi totalité des applications (web ou mobile) sont en code fermé malgré le fait qu'elles utilisent beaucoup de bibliothèques libres
Ce phénomène s'étend au mobile où la plupart des applications sont propriétaires (et produites en quantité astronomiques).

4. La difficulté à protéger sa vie privée

Sur le plan perso, les deux dernières années ont été un peu difficiles. J'ai donc complètement laissé tombé l'idée de protéger ma vie privée depuis. Vous allez me dire que je suis idiot et que c'est mal. Ce n'est pas faux et je ne suis pas venu chercher une rédemption. Mais ce qui m'embête, c'est qu'un convaincu comme moi a du mal à se protéger. Alors comment sensibiliser et motiver des gens pour qui ces questions comptent peu voir pas du tout ? Quand on a déjà du mal à boucler la fin de mois ou qu'on souffre d'une maladie lourde a-t-on encore l'énergie de défendre ses données ?

Bon voilà j'espère n'avoir pas été trop pessimiste mais j'avais besoin de mettre ça sur la table. Pour tempérer, on voit plein de belles initiatives naître régulièrement comme les projets Eelo ou SOLID. D'autres outils comme Mastodon ou Nextcloud rencontre de plus en plus de succès. Tout n'est pas noir.

Projets et contributions

Je contribue peu aux projets des autres mais j'ai quand même pu travailler sur deux d'entre eux: OpenFoodFacts à travers un client Python et Diaspora à travers son API. Je me suis rendu compte que réaliser le code, le proposer, le faire accepter et le voir utilisé, prend vraiment beaucoup de temps. Cela nécessite de la patience. Au début j'étais enthousiaste mais au bout d'un moment j'en ai eu marre. Heureusement pour les deux, j'ai pu passer le relais.

OpenFoodFacts

J'ai travaillé sur un client Python pour l'API openfoodfacts. Il semblerait qu'il soit utilisé par des équipes scientifiques aujourd'hui. Pour déléguer la responsabilité du repo, étant mainteneur, j'ai utilisé la technique d'Hintjens consistant à rapidement accepter les contributions. Cela m'a permis de motiver un nouvel arrivant et de nommer ce contributeur actif comme mainteneur.

Diaspora

Pour Diaspora, je n'ai pas réussi à convaincre les mainteneurs de prendre mon code. Mais maintenir la Pull Request en vie, en ajoutant du code de temps en temps, a motivé un nouveau contributeur pour prendre le relais. C'est assez bizarre de prendre ses Pull Requests sur ma branche mais j'espère que ça aboutira. Cela a pris tout de même plus d'un an.

Player 3D

Dans le cadre de CGWire j'ai du faire un visualiseur de modèle 3D. J'ai pu l'extraire pour en faire un projet à part. C'était assez fun mais en dehors de la découverte de Three.js je n'ai rien appris de particulier.

Code en Espéranto

Je n'ai toujours pas eu la motivation de m'y mettre. Je n'aborderais donc plus le sujet à moins d'avoir un bout de code significatif à montrer.

Communauté serveur personnel

Sur mon temps libre j'ai commencé à travailler sur des projets expérimentaux autour du serveur personnel. Ce qui a aboutit à trois premiers repos :

Awesome Personal Server : une liste de logiciels et hardware utiles au serveur personnel.
Personal Server Checker : Un outil en ligne de commande qui audite les grandes lignes de la sécurité de votre serveur.
Default Stack : une stack docker de base pour développer ses applications webs perso ou pour en déployer des existantes.

Les autres projets sur lesquels j'aimerais prototyper des choses dans ce cadre sont :

Une base de données personnelle : une API (en Elixir) pour stocker des données personnelles avec une optique quantified-self. L'idée serait de stocker les données de tracking dans InfluxDB pour les observer ensuite via Grafana.
Un application web d'agenda personnel basique et facile à utiliser.
Un joli site web informatif ou les gens pourraient publier leur configuration matérielle et logicielle.

Mon but est aussi de monter une communauté autour de cette thématique afin de faciliter et développer cette pratique. En effet le serveur perso permet de nous augmenter en tant qu'être humain tout en respectant notre libre arbitre et notre vie privée. Il y a forcément d'autres gens que moi que ça intéresse. Le compte Personal Server Community est donc ouvert à toute personne qui veut publier un projet lié à ce thème. Il suffit de me demander pour l'ajouter.

Je pense progresser doucement. Je me laisse donc du temps, beaucoup de temps pour avancer dessus. Ca sera mon passe temps préféré et je vous tiendrai au courant de mes progrès. Si certains sont intéressés pour participer, ils sont les bienvenus. Pour le moment le point de discussion central sur ce sujet est l'organisation Gitlab. Vous y êtes les bienvenus !

La suite

Cette année j'ai appris qu'on pouvait vivre d'un logiciel libre, que ce n'est pas toujours évident de croire dans la cause et que les contributions prennent beaucoup plus de temps qu'on imagine. J'ai aussi toujours la sensation de progresser en informatique à travers le logiciel libre même si les résultats m'apparaissent moins clairement qu'au début.

Pour la suite je vais concentrer mes efforts sur CGWire. En parallèle je continuerai à mon rythme mes explorations sur le serveur perso. A travers ces deux activités, j'espère découvrir et apprendre suffisamment de choses pour les partager avec vous l'année prochaine !