Promesse open source
La plupart des logiciels sur lesquels tu comptes chaque jour sont fermés. On pense que c’est en train de devenir un vrai problème. Alors on a fait un autre choix — et on ne reviendra pas en arrière.
Le problème du code fermé
Soyons francs. La plupart des logiciels qui font tourner les équipes modernes – ton CMS, tes outils de design, tes applis de communication – sont fermés. Et pendant longtemps, ça allait très bien. Le logiciel coûtait cher à développer, et les personnes qui le construisaient méritaient de gagner leur vie.
Mais quelque chose a changé. La qualité des logiciels part franchement en vrille, au ralenti, et le plus frustrant, c’est que tu ne peux rien y faire.
Chaque mise à jour, c’est pile ou face. Est-ce que ce sera mieux ? Pire ? Est-ce que la fonctionnalité dont dépend ton workflow va casser en douce ? Tu n’en sais rien, parce que tu ne peux pas voir le code. Tu ne peux pas le corriger. Tu ne peux pas le forker. Tu es juste coincé, à espérer que l’équipe se soucie assez de faire les choses correctement.
L’ère de l’IA a rendu ça beaucoup pire. Les équipes livrent plus vite que jamais – mais plus vite, ce n’est pas mieux si personne n’est responsable de la qualité de ce qui sort. Dans l’ère de l’IA, le fermé veut dire que les bidouilles s’accumulent dans le silence, et tu ne le découvres que quand ça cesse de marcher.
Nous refusons de construire ce genre de produit.
Ce qui se passe quand tu peux voir le code
Il se passe quelque chose dès que tu rends open source quelque chose de vraiment utile. D’un coup, tu ne peux plus te cacher derrière des roadmaps vagues ou des « on y travaille ». Le code est là, sous tes yeux. Tes utilisateurs peuvent le lire, le forker et te pointer du doigt publiquement quand ça part dans la mauvaise direction.
C’est précisément cette responsabilité qu’on veut.
Quand b10cks prend un mauvais virage – et tout projet finit par en prendre un – tu n’attends pas qu’on mette ton problème en haut d’une liste de tâches interne. Tu peux regarder le code, comprendre ce qui se passe et le corriger. Tu peux soumettre une PR. Tu peux forker et partir dans ta propre direction. Ou tu peux simplement nous montrer du code fonctionnel qui prouve que ta solution est meilleure.
C’est comme ça que le logiciel devrait fonctionner. C’est comme ça que b10cks fonctionne.
Le principe de Yash
Il y a un changement de mentalité qui distingue les grands ingénieurs des bons. Les grands ingénieurs n’acceptent pas les limites arbitraires dans les systèmes avec lesquels ils travaillent. Quand quelque chose ne fonctionne pas comme il faut, ils ne bricolent pas autour. Ils vont à la source et ils corrigent.
Le logiciel fermé rend ça impossible. Tu tombes sur un mur, et ce mur est bien réel. Tu ne peux pas le contourner. Tu dois composer avec, vivre avec, ou quitter complètement l’outil.
L’open source fait tomber les murs. Quand b10cks fait quelque chose qui ne colle pas à tes besoins, tu n’es pas à la merci de notre planning de sprints. Tu as le code source. Tu peux le comprendre, le modifier, le patcher et lancer dès aujourd’hui ta version corrigée en production.
J’ai rendu b10cks open source parce qu’on pense que les développeurs qui l’utilisent méritent de travailler comme ça, et parce que je voulais vivre avec la même exigence de responsabilité.
La licence n’est pas une faille
J’ai vu ce que « open source » veut parfois dire dans la vraie vie : une version gratuite qui ne couvre rien, un dépôt public sans vrai code dedans, ou une licence qui est open source jusqu’au moment où quelqu’un veut vraiment s’en servir commercialement.
b10cks est sous licence GNU Affero General Public License v3. Voilà ce que ça signifie concrètement pour toi :
Tu peux l’héberger toi-même. Pour toujours. Pas besoin d’autorisation, pas de clé de licence, pas d’appel avec notre équipe commerciale. Tu clones le dépôt, tu lances Docker, et c’est parti.
Tu peux lire chaque ligne de code. Le produit entier. Pas de bundles obscurs, pas de cœur fermé avec une couche open source par-dessus. Ce que tu utilises, c’est ce qui est sur GitHub.
Tu peux le forker. Si nos choix ne te conviennent pas, tu peux faire évoluer le projet dans la direction que tu veux. Si tu l’améliores, tu reverses ces améliorations au projet. C’est l’accord — et il est juste.
L’AGPL ferme la porte à l’astuce du cloud. Certaines entreprises ouvrent leur code en sachant très bien que personne ne peut vraiment rivaliser avec leur service managé. L’AGPL signifie que si quelqu’un construit une activité sur b10cks, ces modifications restent ouvertes. La communauté qui a construit ça reste protégée.
Nous gagnons de l’argent en proposant un excellent produit hébergé. Pas en t’y enfermant.
Pourquoi c’est encore plus important à l’ère de l’IA
Voici la vérité inconfortable sur le développement assisté par l’IA : il amplifie les incitations déjà en place. Les équipes qui privilégient la qualité livreront de meilleure qualité, plus vite. Les équipes qui privilégient la livraison livreront de la bouillie, plus vite.
Dans un environnement fermé, tu n’as aucun moyen de savoir à quelle sauce tu es mangé avant que les dégâts soient faits. Tu ne peux pas auditer la base de code. Tu ne peux pas voir ce qui a été fusionné sans relecture. Tu ne peux pas suivre le ratio entre une architecture réfléchie et des patchs générés par IA que personne n’a vraiment compris.
L’open source est la réponse à ça. Le code est visible. L’historique des commits est visible. Les PR, les revues, les discussions – tout est public. Si b10cks commence un jour à livrer de la bouillie, tu le verras avant de le subir. Et tu auras les outils pour agir.
Chez Coders Cantina, nous avons mis notre réputation dans la création d’une technologie qui sert réellement les personnes qui l’utilisent – pas dans une technologie optimisée pour les métriques de rétention au détriment de la qualité. L’open source, c’est la façon de prouver cet engagement, pas seulement de l’affirmer.
Les engagements
Le code restera toujours public.
Nous ne mettrons jamais les fonctionnalités essentielles derrière un paywall fermé ou un wrapper propriétaire. Ce que tu peux héberger toi-même correspondra toujours à ce que nous faisons tourner dans notre cloud.
Nous ne changerons jamais la licence en douce.
b10cks est sous AGPLv3 et le restera. Passer à une licence plus restrictive exigerait l’accord de chaque contributeur – ce n’est pas possible, et ce n’est pas quelque chose que nous voudrions faire.
Nous ne prendrons jamais tes contenus en otage.
Export complet des données à tout moment, dans des formats standards. Ton contenu vient de ton équipe. Il appartient à ton équipe.
Nous maintiendrons une version hébergeable par toi-même.
Tant que b10cks existera, l’installation Docker fonctionnera. Le cloud managé est une couche de confort, pas une obligation.
Nous construirons en public.
Notre feuille de route, nos tickets, nos choix d’architecture. Tu n’auras pas à deviner ce qui arrive ni pourquoi nous avons construit les choses d’une certaine façon.
Le cas d’usage business de l’open source
Certaines personnes entendent « open source » et pensent que ça veut dire non viable, ou un cadeau financé par du capital-risque qui finit tôt ou tard par un pivot ou un changement de licence. On a déjà vu cette histoire.
b10cks repose sur un modèle simple : le logiciel est libre et ouvert. L’hébergement managé – la tranquillité de ne pas gérer l’infrastructure – est ce que nous facturons. C’est tout. Le stockage et le trafic. Pas de tarification par utilisateur. Pas de paliers de fonctionnalités. Pas d’upsell.
Ça fonctionne parce que les personnes qui gèrent leur propre infrastructure feront exactement ça. Celles qui veulent un produit hébergé fiable et bien entretenu paieront un prix juste pour l’avoir. Et la qualité du produit hébergé reste honnête grâce au fait que l’alternative auto-hébergée est toujours à un git clone près.
Nous ne sommes pas les premiers à essayer ce modèle. Nous sommes simplement ceux qui construisent le CMS dont ton équipe a vraiment besoin – avec la conviction que la bonne façon de faire du logiciel est la seule façon dont nous voulons travailler.
Depuis Vienne, avec profondeur
Coders Cantina est née de la conviction que la technologie doit servir l’épanouissement humain, pas seulement des métriques d’efficacité. Dit comme ça, ça peut sembler abstrait jusqu’au jour où tu vois ton équipe perdre une demi-journée à se battre avec un CMS cassé par une mise à jour silencieuse, ou perdre deux semaines dans une migration fournisseur parce que ton ancien prestataire retenait ton contenu dans un format propriétaire.
Nous construisons avec l’instinct de l’artisan : la qualité avant la vitesse, la profondeur avant les métriques superficielles, de vrais partenariats plutôt que des relations transactionnelles. Pour nous, l’open source n’est pas seulement un choix de licence – c’est l’expression structurelle de ces valeurs. Cela signifie que nous pouvons être jugés selon le standard que nous revendiquons.
La « technologie avec une âme » commence par un logiciel en lequel tu peux avoir confiance parce que tu peux le lire.
L’open source n’est pas un compromis. C’est tout l’intérêt.