Construire une application en public, tout seul

J’écris Shale seul. Pas en secret : les versions sortent, les notes de version disent ce qui change, et quand je corrige un défaut, je le dis aussi. C’est la partie que les gens trouvent étrange — pourquoi annoncer un défaut plutôt que de le laisser passer inaperçu.

La réponse est simple. Un logiciel payé par ses utilisateurs n’a qu’une seule dette : envers eux. Pas envers un investisseur qui attend une courbe, pas envers une équipe commerciale qui a promis une fonctionnalité. Cette dette-là se rembourse en disant la vérité sur l’état du produit.

Ce mois-ci, la ligne que je relis le plus est une correction

Septembre a apporté le calendrier, les liens entre notes, tâches et objectifs, les cartes mentales et la facturation. Mais dans les notes de version, la ligne qui compte le plus pour moi est une correction : pendant quelques jours, le contenu d’une note pouvait s’afficher dans la suivante quand on changeait de note très vite. Aucune note n’a été perdue.

Je l’ai écrite quand même. Un défaut qu’on ne dit pas, les gens finissent par le trouver seuls — et ils en concluent, avec raison, que le reste est tu aussi.

Construire en public, ce n’est pas se raconter

Il existe une version fatigante de cette pratique : le développeur qui publie son chiffre d’affaires chaque semaine, transforme chaque correction de bug en récit héroïque et parle davantage de son parcours que de son logiciel. Ce n’est pas de la transparence, c’est du marketing avec un ton différent.

La version qui m’intéresse tient en trois habitudes. Dire ce que le produit ne fait pas, sur la page d’accueil, avant que quelqu’un l’ait découvert à ses frais. Écrire les notes de version en incluant les défauts corrigés. Répondre soi-même au support, ce qui est le meilleur moyen connu de savoir où le produit fait mal.

Ce que ça coûte vraiment

Il n’y a personne pour me dire qu’une idée est mauvaise. Aucun garde-fou, aucune revue de code, aucune réunion — ce qui est un confort et un danger.

Il y a aussi la question que tout le monde pose, à juste titre : et si j’arrête ? La seule réponse honnête n’est pas une promesse, c’est une propriété technique. Le fichier de données vit sur votre machine. Si le développement s’arrête demain, votre travail reste sur votre Mac. C’est pour ça que Shale fonctionne hors ligne : ce n’est pas un argument de vente, c’est une clause de sortie.

Ce que je fais ensuite

Le calendrier et la facturation viennent de sortir. La suite est l’application iPhone — celle qui existe et tourne, mais que je refuse de distribuer avant qu’elle soit bonne. Windows après, sans date annoncée, parce qu’annoncer une date que je ne tiendrai pas serait exactement le genre de chose que cette façon de travailler cherche à éviter.

Chaque changement est daté dans les notes de version, corrections comprises.