Journal Quatre ans de projets libres : bilan et retour d'expérience

Sommaire

• Ce que j'ai fait cette année
• Développement
• Entreprise
• Et ensuite ?

Et voilà  le 4ème post sur mon retour d'expérience de développeur de logiciels libres. Cela avait démarré il y a quatre ans avec Newebe un projet de réseau social distribué en Python. Au bout d'un an de code j'avais écrit un billet de blog pour faire le bilan de l'année écoulée autour de mon expérience de développeur libre (1). J'ai perpétué ce principe les deux années suivantes (2, 3). Entre temps j'ai démarré un autre projet beaucoup plus ambitieux nommé Cozy, un cloud personnel libre. Aujourd'hui je remets donc le couvert pour faire le bilan de mon année la plus active dans l'univers du logiciel libre.

Ce que j'ai fait cette année

Point de vue code, j'ai terminé et réalisé la nouvelle interface de Newebe et j'ai poussé les premiers commits d'une version Node.js de ce projet. J'ai fait l'effort de fournir de nombreux moyens de déploiement (paquet Debian, Dockerfile, recette Ansible, intégration au projet Sovereign). Toutefois j'ai avancé beaucoup plus lentement que les années précédentes. En effet, l'ensemble de mon temps s'est porté sur Cozy. C'est assez logique étant donné que c'est mon activité professionnelle et entrepreneuriale. Je suis intervenu sur l'ensemble de la plate-forme et de ses applications tant en développement qu'en facilitateur de communauté.
Sur mon temps libre j'ai continué à  maintenir la lib request-json, un client HTTP adapté aux interfaces REST et JSON, KYou et Konnectors des applications Cozy de Quantified Self et j'ai démarré Cozy Light une version minimaliste de Cozy facile à déployer.
Le projet entrepreneurial Cozy Cloud s'étant affirmé (nous sommes une équipe de développement constituée d'une petite dizaine de personnes), j'ai pu aussi constater l'impact du développement libre sur notre organisation.

Développement

Cette année j'ai pris mon rythme de croisière, je n'ai pas changé grand chose à  mon mode de développement. Les deux plus grosses modifications que j'ai faites sont un changement de thème de couleur vi et un test de ZSH (toujours en cours). Par contre, mes nouvelles facilités à  mettre en oeuvre un projet m'ont incité à  me disperser. Vouloir continuer à expérimenter tout en améliorant Cozy m'a poussé à coder beaucoup de choses rapidement. C'est une étape intéressante à traverser mais j'espère pouvoir me limiter sur la quantité de fonctionnalités produites en faveur de la qualité. J'aimerais pour l'année à  venir retourner à  une manière de coder plus patiente.
Pour faire un parallèle, quand on fait de l'escalade on se rend compte qu'en prenant bien le temps de poser ses appuis on fournit beaucoup moins d'efforts pour atteindre l'étape suivante. Je trouve que pour le code les choses sont un peu pareilles. Pour bien avancer dans son programme il vaut mieux bien valider chaque étape. Sinon au milieu du parcours on se retrouve épuisé.

Il faut savoir accepter qu'un projet est fini. J'entends par là  qu'il ne mérite plus que de la maintenance. En effet on a trop tendance à  vouloir toujours rajouter des fonctionnalités. Mais au bout d'un moment il faut simplement s'arrêter et se dire que le projet fait bien ce qu'il doit faire. Cet état est atteint pour request-json et Newebe s'en rapproche.

Faire des choses simples c'est difficile. J'en ai pris pleinement conscience récemment lorsque j'ai développé Cozy Light, une version minimaliste de Cozy. Le code ne fait que 800 lignes contre des dizaines de milliers pour Cozy. On pourrait penser que coder Cozy Light est plus facile. Pourtant il m'aurait été impossible de le réaliser sans avoir travaillé sur la version complète.

Pour illustrer je vais prendre la série de dessins suivants qui était distribuée aux employés d'Apple pour leur montrer le processus de simplification appliqué à  leurs produits. On voit avec le dernier dessin qu'on peut garder l'essence d'un dessin complexe en ne préservant que quelques lignes. Cette légèreté est particulièrement efficace en logicielle car elle permet d'arriver aux mêmes fins qu'un logiciel complexe avec une maintenance grandement amoindrie. Cet exemple est intéressant mais ce qu'on oublie souvent de dire à son propos, c'est que pour obtenir le dernier dessin, il a fallu être capable de dessiner le premier dans toute sa complexité.

Point de vue des technos je suis beaucoup rester dans l'univers Javascript/Coffeescript au détriment de Python. Aujourd'hui les deux langages que je voudrais explorer sont Go et Lua. Go car il parait qu'il possède beaucoup de fonctionnalités facilitant la vie du développeur, ça doit donc être enrichissant à  utiliser. Lua m'attire de par ses caractéristiques de légèreté. En effet cette techno me semble bien adaptée à l'auto-hébergement .

Je me sens plus à  l'aise avec l'éco-système Node.js, j'y participe plus. J'ai dû comprendre le fonctionnement de bibliothèques bas niveaux pour résoudre certains bugs. J'ai contribué à des bibliothèques réalisées par d'autres. J'ai même eu l'occasion de résoudre un bug en collaboration avec un autre contributeur que les principaux, c'était particulièrement enthousiasmant.

De manière plus générale j'ai du ressortir mes livres de système pour bien comprendre comment ça fonctionnait en dessous. J'ai une meilleure compréhension de l'ensemble de l'environnement dans lequel évolue mes programmes.

Enfin, je code plus vite. Je me pose beaucoup moins de questions quand je démarre un projet ou que je rajoute une fonctionnalité. Et ça c'est agréable !

Entreprise

Le rapport du logiciel libre et de l'entreprise est particulier. Il bouscule les habitudes. Du point de vue financier, il pose la question de comment gagner de l'argent avec un produit que l'on peut acquérir sans payer. Du point de vue éthique, il pose la question de comment respecter les principes du logiciel libre avec une logique de croissance soutenue et permanente. Chez Cozy nous avons dû donc construire notre projet pour satisfaire les deux parties prenantes que sont nos financeurs et la communauté. Pour cela une logique basée sur la mutualisation de service et la licence AGPL ont été de bons outils. L'un nous ayant permis de justifier un besoin fort de services rémunérés autour de notre solution, l'autre en tant que garde fou au cas où nous ne respecterions plus la philosophie initiale du projet. Mais au final ce n'est pas surprenant que nous ayons réussi à  trouver une harmonie. Les licences libres sont des outils, leurs caractéristiques sont découplés des intentions.

Faire du logiciel libre en entreprise m'a permis de m'entourer de gens compétents qui partagent les mêmes principes que moi. C'est assez agréable de se faire reprendre car il n'y a pas assez de tests sur tel module, d'avoir des collègues qui se posent des questions sur la pertinence de la longueur d'un sprint ou de soulever des débats intéressants sur tel choix de technologie. Sans parler de la veille permanente réalisée par le groupe qui fait que je n'ai plus tant besoin de me renseigner sur les dernières nouveautés.

La logique collaborative favorise l'efficacité. D'une part la mise en commun des savoirs et des productions crée un cercle vertueux. D'autre part quand on est prêt pour accueillir de nouveaux contributeurs, on est prêt à recevoir un nouveau collaborateur à temps-plein. Enfin, les communications sont mieux organisées et tout est historisé.
NB : Pour une entreprise où tout le monde est en télétravail, cela fonctionne d'autant mieux.

Recevoir les retours et les contributions de la communauté est très efficace. Le regard neuf et extérieur des contributeurs nous permet de savoir plus facilement sur quels points se concentrer pour arriver à  un produit fini. C'est aussi très motivant de recevoir de l'aide de gens extérieurs.

Les peer reviews sont bénéfiques. Chez Cozy nous les avons mises en place plus systématiquement et le gain en qualité s'en ressent vraiment. Autant je ne regrette pas qu'avant cela, nous n'en faisions pas plus (nous avions besoin d'aller vite, nous n'avions pas encore bien pris nos marques) autant aujourd'hui elles me paraissent très utiles étant donné la quantité de code que nous devons maintenir.

Enfin j'ai pu défendre notre cause dans des endroits moins avertis (événements startups principalement). Toutefois je n'ai pas su le faire en employant le terme de logiciel libre. J'ai parlé de logiciels "open source".

Et ensuite ?

C'est tout pour cette année. Je n'ai pas évoqué les différents événements (JDLL, RMLL, OWF, etc..) auxquelles j'ai participé. Ils sont toujours aussi sympathiques et bouillonnants d'idées. Pour en revenir au code, je pense que pour l'année à  suivre je vais essayer de contribuer un peu plus à  des projets autres que les miens. J'espère également que la communauté Cozy va grandir suffisamment pour que nous ayons la possibilité de devoir mieux gérer les contributions extérieures et penser ainsi à un mode de gouvernance plus évolué. En somme, j'ai encore vécu une année pleines de découvertes et j'espère que l'année prochaine sera aussi palpitante !