Pourquoi je ne fais pas d'open source sur Writizzy

Pourquoi faire de l’open source aujourd’hui ?

Ou… pourquoi ne pas en faire ?

Je développe un produit, writizzy.com et j’ai commencé à me poser cette question en me demandant, comment faire un logiciel durable ? Est-ce que l’open source est une piste pour ça ?

Au delà de la durabilité, je travaille depuis le début des années 2000 et globalement mon métier a drastiquement changé. Une des grandes raisons est lié à l’essor de l’open source.

Alors certes, quand j’ai démarré mes études d’informatique en 1997, on travaillait déjà sur linux avec de nombreux logiciels open source mais mes premières expériences dans le monde du travail, ressemblaient surtout à de l’archéologie. Ma mission était de retrouver les CD de documentations disséminés dans les étages, et d’interroger les bons experts pour comprendre pourquoi le logiciel qu’on utilisait réagissait de telle ou telle façon. Sans avoir accès au code source il fallait deviner comment ça marche et surtout il fallait réinventer la roue sans arrêt pour a peu près tout, ce qui donnait des logiciels de qualité très discutables.

J’ai vu mon métier changer et l’open source devenir une des fondations de tout l’informatique moderne. Alors oui, j’ai envie de contribuer à mon tour.

Mais j’appréhende les contraintes qui vont avec.

Je suis tiraillé entre la volonté d’un retour à un web plus ouvert et, basiquement, les impératifs économiques.

C’est ce dilemme que je veux explorer ici. À travers l’exemple de Writizzy, voici pourquoi j’hésite à ouvrir mon code, ce que j’aimerais pourtant faire, et ce que j’envisage pour la suite.

Les bénéfices de l’open source

Bon déjà, pourquoi faire de l’open source ? A chaud je dirais :

pour contribuer à un écosystème
pour une distribution plus large
pour les contributions et la sérendipité
pour la transparence
pour un web plus ouvert

Mais comme on va le voir, c’est pas si simple.

Un marketing et une distribution simplifiée

On va pas se mentir, l’open source est un levier de communication. L’open source permet un usage plus large et donc se de faire connaitre par bouche à oreille. C’est la possibilité d’avoir des hébergeurs qui proposeraient Writizzy en marque blanche, ou des utilisateurs qui pourraient faire leurs propres themes/plugins et les vendre sur une marketplace (comme Ghost). Ca a l’air de rien mais dès lors qu’une économie se met en place autour de votre produit, cela lui garantit une certaine notoriété. C’est de la “pub” gratuite.

Ok mais, à quel prix ?

Que ce soit Wordpress, Ghost ou Gitlab, combien utilise vraiment le service commercial proposé par l’éditeur ? Et combien de services commerciaux se sont greffés autour de ces logiciels, tout en évitant de contribuer directement au projet open source ?

Voici les chiffres d’affaires annuel estimé pour plusieurs concurrents de Writizzy :

Substack : 45 M$
Beehiiv : 30M$
Ghost : 10M$

Ghost est la seule plateforme open source des 3. On estime que l’économie qui gravite autour de Ghost créé environ entre 15 et 25M$.

C’est a dire qu’environ 20M$ est capté en dehors de Ghost.

Imaginons que Writizzy marche, soyons fou, est-ce que j’ai pas le risque d’avoir des acteurs qui exploitent commercialement Writizzy, ne contribuent pas au projet open source, profite de mes investissements en publicité, et me laisse gérer toute la difficulté de la maintenance du logiciel ?

Oui l’open source c’est noble, mais ça fait pas manger et je veux pas finir comme l’un de ces innombrables projet open source qui survit péniblement et qui finit par fermer.

Deux options sont possibles, avoir une license restrictive qui empêche un usage commercial, ou juste… s’en fouttre.

Ghost s’en fout. Parce que c’est une boite sans actionnaires à rémunérer et qu’ils ne recherchent pas la maximisation de leur profit.

Mais si j’y réfléchis bien, c’est pareil pour moi. Bon déjà, je serais très heureux d’avoir ne serait-ce que le 10eme de la réussite de Ghost. Si j’y arrive, en partie, parce que le modèle open source a permis de faire parler du produit, je peux aussi me dire que j’ai atteint mon objectif non ? Et puis bon, ce serait hypocrite de ma part, moi aussi j’utilise des briques open source pour aller plus vite, non ?

Je créé un produit commercial, je ne vais pas le cacher. Mais je ne vise pas à créer une multinationale de 400 personnes donc, avoir un écosystème qui se créé autour du projet et qui vit dans son coin mais qui fait aussi augmenter la visibilité du projet, pourquoi pas ?

Après, je veux pas laisser penser que “open source = succès” magiquement. Si le projet n’intéresse personne, ce sera peut-être pareil même en open source. C’est un peu ce qui m’est arrivé sur Bloggrify.

Les contributions (inattendues) de la communauté

Vous savez comment un produit s’améliore ? Par les retours de ces utilisateurs.

J’ai l’habitude de dire, “on n’a jamais raison tout seul”.

Vous pouvez être un expert de votre propre logiciel, c’est en le confrontant avec de véritables utilisateurs que ce logiciel devient vraiment parfait.

Parce que chaque utilisateur peut venir avec des nouvelles idées, parce que vous pouvez mesurer ce qui est le plus important pour les gens et donc mieux prioriser ce qu’il faut faire ou parce que vous pouvez avoir des contributeurs directs.

Si une personne améliore votre produit, c’est une contribution utile pour tous.

Mais ça vient avec un coût, devoir répondre nuit et jour à une horde d’utilisateurs, pas toujours très respectueux du travail fourni gratuitement. Rappelez vous :

de Jacob Thornton, co créateur de Twitter Boostrap qui a clairement fini en burnout
de Salvatore Sanfilippo, créateur de Redis qui a également fini par craquer

Enfin ça c’est quand il y a un un succès. Dans la grande majorité du temps, votre projet va juste avoir 0 utilisateurs et presque aucun retours.

Dans le passé j’avais créé deux projets qui sont plutôt tombés dans cette catégorie :

pg-mongo-streamer: un connecteur pour alimenter pgsql en répliquant en temps réel les events mongo
Bloggrify, un générateur de blog statique, une sorte d’équivalent à Jekyll dans l’écosystème Nuxt

Dans les deux cas, la base utilisateur a été très faible donc les retours quasi inexistants. Dans le cas de Bloggrify, c’est surtout devenu une charge de travail pour essayer de mettre en place certains standards d’un projet open source, pour un résultat quasi nul.

Quoi qu’il en soit, oui, cette dimension me fait peur. Je ne peux que souhaiter que Writizzy ait de la traction et me retrouver dans le premier cas. Et en même temps, j’ai peur de pas être capable de suivre.

J’admets que je comprends largement Ben Johson (litestream) qui a choisi de limiter l’ouverture à la contribution pour protéger sa santé mentale et la viabilité du projet, autrement dit, choisir l’open source mais limiter la contribution. Aujourd’hui mon sujet n’est pas d’aller plus vite en termes de production de code de toute façon.

Maintenant quand je parle de contributions, je pense également en termes d’écosystèmes. C’est l’opportunité qu’il y ait des choses qui se créent de façon inattendue. Ca peut être des marketplaces de thèmes, des hébergement communautaires, des plugins, des… trucs… par définition si c’est inattendue je peux pas tellement les lister en fait :)

La transparence : exposer ses faiblesses

Un projet open source inspire confiance, en théorie. Il donne l’illusion que, étant ouvert, tout son code a été adoubé par une communauté d’expert.

Dans la réalité, ouvert ne veut pas dire être lu. Je doute que vous ayez été lire le code source de la grande majorité des outils que vous utilisez sous linux par exemple et vous n’êtes pas le seul. On pourrait citer l’affaire de la porte dérobée dans xz ou de la CVE log4shell.

Quoi qu’il en soit je reste persuadé que c’est préférable à un logiciel fermé. Est-ce que la sécurité par l’obscurité marche vraiment ? Pas vraiment, et c’est parfois l’éditeur lui-même qui place des portes dérobées dans son logiciel.

Mais justement, si j’ouvre le code de Writizzy demain, je suis pas totalement serein. J’ai fait tout mon possible pour que ce soit un logiciel bien conçu et sécurisé mais, soyons honnête, est-ce que je suis sûr à 100% que personne ne trouvera de failles de sécurité ? Non pas du tout. Un ami m’avait d’ailleurs détecté des failles dans Writizzy il y a quelques mois. J’ai des utilisateurs en production, que se passe-t-il si des individus malveillants recherchent activement des failles sur mon code à chaque release ? Ca fait clairement partie de mes craintes.

Pour ce qui est de la "qualité” du code, c’est un autre sujet. Je trouverais toujours des gens pour critiquer mais ça fait 25 ans que je travaille, ça me glisse un peu dessus. La critique est facile, l’art est difficile. Mais pour la sécurité, c’est un autre sujet, impossible à ignorer.

Et aujourd’hui j’ai pas de notion de version. Je mets en production en continu. Est-ce que je dois abandonner ce principe pour laisser un temps de repos avant la mise en production d’une nouvelle version ? Ce serait de la lourdeur supplémentaire que je m’imposerais et je n’ai pas forcément le luxe de pouvoir le faire.

Donc oui, partiellement aujourd’hui je compte sur le fait que personne ne peut lire les erreurs que j’ai pu faire avant que je les corrige. Si c’était open source, ce serait plus le cas. Ca m’imposerait une autre façon de travailler, plus lourde, et plus dangereuse pour mes utilisateurs. C’est clairement un frein.

L’architecture Writizzy est-elle compatible avec un projet open source ?

Un autre point qui m’inquiète, à partir du moment où j’ouvre le code, c’est que Writizzy a une certaine complexité architecturale. Pour faire tourner l’application c’est aujourd’hui :

1 API kotlin
1 app front pour la partie CMS
1 app front qui fait tourner le blog
un base de données postgresql
un file de message RabbitMQ

Un utilisateur pourrait souhaiter avoir une seule application et je le comprends.

Toute mon architecture repose sur le fait que je fais tourner tout les clients sur la même instance en multi tenant et j’ai tout le site commercial qui exploite mes utilisateurs dans l’application “CMS”.

Comment faire pour proposer ça en open source ? C’est très loin d’un standard comme Ghost ou Wordpress.

Bon après ce serait pas le seul logiciel comme ça. J’ai récemment installé posthog et il suffit d’utiliser un Docker compose pour cacher cette complexité donc je suppose qu’on peut trouver une solution. J’ai même envie de dire que c’est devenu la norme, désormais la brique unitaire pour installer c’est le docker compose.

Par contre, j’imagine qu’il faudrait que je sépare vraiment la partie admin et site commercial du CMS (EDIT : c’est fait depuis aujourd’hui). Cette partie là resterait en propriétaire. Et il faudrait un mode “mono tenant” pour cacher toute la complexité du multi tenant de façon à ce qu’un utilisateur puisse juste lancer son app pour lui-même.

Si j’ai des pistes, çà n’en reste pas moins des contraintes supplémentaires.

Et le plan pour Writizzy ?

Bon et donc, quel est le plan ? Je construis Writizzy avec une envie aussi de retrouver un web plus ouvert, de sortir des plateformes US, d’inciter les gens à écrire aussi. Parce que écrire, lire, s’informer, est plus que nécessaire dans le monde actuel.

Dans un précédent article je m’interrogeais sur le fait de créer un logiciel durable, l’open source faisait partie des solutions.

Donc oui, je suis partagé. J’aimerais à un moment en faire un produit open source. Concrètement, j’ai commencé à faire des modifications importantes du logiciel pour séparer la partie “commerciale” de l’application elle-même.
J’ai une trajectoire en tête pour isoler ce qui relève de mon application qui permet de vendre et hoster writizzy, du reste, le CMS et le blog.

C’est en cours. Ca permet aussi de se reposer des questions sur les dépendances, de simplifier. Mais peut-être que ça n’aboutira pas.

J’ai pas envie de refaire les erreurs de Bloggrify (trop de lourdeurs pour pas grand chose). Et peut-être que je devrais attendre de voir que Writizzy ait plus de hype derrière lui ? Beaucoup de questions, peu de réponses :)

En tout cas si vous avez de l’expérience sur des projets opensource, vos retours m’intéressent.