Un hadron est une particule composite, composée de particules subatomiques régies par l'interaction forte, nous dit Wikipédia. Si cela vous fait penser à Proton, ce n’est peut-être pas parce qu’un proton est un hadron, mais parce que Hadron, comme Proton, promet de faire tourner vos jeux (et plus) n’importe où, même sur des systèmes terreux.

Vous connaissez peut-être Proton, l’assemblage de Wine et d’autres composants libres que Valve emploie pour faire tourner des jeux Windows sous Linux pour sa plate-forme Steam. Hadron propose la même chose pour macOS.

Des jeux Windows ? Sous macOS ? Quel est le 🌀️💀️⚡️⁉️ de rapport avec LinuxFr.org et son objectif de promotion des logiciels libres ? C’est parce que Hadron est construit de briques libres du sol au plafond : Wine, FEX, Mesa, vkd3d…

Sommaire

• Pourquoi Hadron ?
• L’architecture de Hadron
  • FEX, le traducteur automatique d’instruction processeur
  • Wine, l’implémentation libre des API Windows
  • Mesa, Zink et KosmicKrisp
  • vkd3d-proton, DirectX 12 sur KosmicKrisp
  • mtld3d et DXMT, les plus anciens Direct3D sur Metal
• Win32 + Vulkan + AMD64, la plate-forme universelle ?

Le logiciel libre 7zFM pour Windows x86-64 s‘exécutant sur un Mac mini M1 sous macOS 27 sans utiliser Rosetta 2.

Le développement de Hadron est encore très jeune, confidentiel, mais très rapide et réactif. Votre serviteur a testé de faire tourner le jeu libre Unvanquished et a rencontré deux bugs (1, 2) qui ont tous deux été corrigés dans les deux jours (1, 2), et une nouvelle version incorporant les correctifs a été publiée sous cinq jours (1).

Les spéculations sur « qui est derrière Hadron » pourraient se tourner naturellement vers Valve, qui est le premier bénéficiaire économique d’un tel système, mais le README du projet Hadron est explicite : « It is unofficial. Hadron is not affiliated with or endorsed by Valve, Apple, CodeWeavers or any of the projects it builds on », « C’est un projet non officiel. Hadron n’est ni affilié à, ni approuvé par Valve, Apple, CodeWeavers ou l’un des projets sur lesquels il s’appuie ».

Il semble donc que Hadron soit simplement l’initiative de son auteur David Andrews (Broyojo), ni plus ni moins.

Au delà de la proximité de nom entre Hadron et Proton, Hadron reste délibérément focalisé sur Steam : la fenêtre qui s’affiche quand vous lancez Hadron ne sert qu’à intégrer Hadron à Steam, et les premières versions ne proposaient d’ailleurs pas d’option pour lancer un programme non-Steam (fonctionnalité ajoutée très rapidement en quelques jours aussi). Le but premier de Hadron est Steam, et quand vous rapportez un bug pour un jeu, il vous est demandé l’identifiant Steam de ce jeu (cet identifiant est heureusement optionnel).

Pourquoi Hadron ?

En 2027, Apple sortira macOS 28 et à cette occasion, a prévu de drastiquement réduire l’étendue de la compatibilité Rosetta 2. Rosetta 2 est le système de traduction automatique qui permet de faire tourner des binaires amd64 (x86-64) sur arm64 (Apple Silicon ici, dans les macs « M »). Rosetta 2 a un 2 parce que Rosetta premier du nom s’occupait de traduire les binaires PowerPC vers Intel il y a très longtemps. Par commodité nous dirons simplement Rosetta au lieu de Rosetta 2 dans la suite de l’article.

Apple a annoncé que Rosetta ne sera plus disponible pour les applications, mais qu’ils conserveront une petite sous-partie prévue uniquement pour faire tourner des vieux jeux non maintenus s'appuyant sur des bibliothèques pour Intel (« we will keep a subset of Rosetta functionality aimed at supporting older unmaintained gaming titles, that rely on Intel-based frameworks » (source). C’est une affirmation super floue. Que restera-t-il de Rosetta ? Sur quoi pourra-t-on compter et ne pas compter ?

Pour Apple, décommissionner Rosetta a un intérêt : ne plus fournir toutes les bibliothèques systèmes en double, ne plus avoir à apporter de la maintenance et du code système pour l’architecture amd64, etc. Tout l’effort de migration vers arm64 est entièrement externalisé vers le développeur indépendant. Ça coûte très cher à l’échelle globale, mais rien du tout pour Apple, et leur clientèle est suffisamment captive pour que le développeur au milieu y soit contraint. Si un développeur échoue à porter son logiciel, le développeur perdra des ventes, mais pas nécessairement Apple. Ce n’est pas le problème d’Apple, surtout quand l’acquisition du logiciel a lieu probablement en dehors de leur marché. Ceci est d’autant plus vrai en dehors du jeu : un logiciel de production concurrent remplace facilement un autre s’il venait à disparaître.

Pour un consommateur de jeu, c’est insupportable : il ne veut pas perdre son jeu parce que le développeur ne le développe plus. Il y a un attachement affectif, le joueur y a investi une partie de sa vie, il peut être attaché à l’histoire, etc. Et si le jeu est encore développé, le joueur ne trouve pas d’intérêt à ce que le développeur se retrouve avec plus de travail qui ne lui apportera aucun changement en jeu. Rajouter gratuitement du travail au développeur de jeu n’apporte rien au joueur.

Et pour une plate-forme tierce de vente et de location de logiciels comme Steam et autre GOG GALAXY, c’est une catastrophe : si un développeur échoue à porter son logiciel, ou n’est plus disponible pour cette tâche, ce sont des ventes en moins pour le développeur et pour le vendeur. Un vendeur de jeux qui prend sa commission à chaque vente (et dont ce serait la première sinon la seule activité économique) a intérêt à ce que le moindre effort soit proposé aux développeurs de jeux.

L’architecture de Hadron

Ne pas confondre avec le Grand collisionneur de hadrons ! L’architecture de Hadron est très différente, mais fait aussi se rencontrer plein de particules élémentaires libres pour observer des effets très intéressants.

Diagramme de l’architecture de Hadron, telle que décrite dans la documentation du projet.

FEX, le traducteur automatique d’instruction processeur

Comme alternative à Rosetta pour traduire les instructions amd64 vers arm64 pour exécuter des logiciels, il existe au moins deux logiciels libres : FEX (dont le développement était initialement secrètement soutenu par Valve), et Box64 développé par notre ptitSeb national.

Ces deux logiciels libres ont été à la base développés pour s’exécuter sous Linux. Hadron a choisi FEX et le fait tourner sous macOS. Ainsi, plus besoin de compter sur Rosetta et d’être dépendant du bon-vouloir d’Apple !

Le choix de FEX correspond bien à l’écosystème de Valve : l’intégration de FEX peut prendre exemple sur celle déjà réalisée pour Steam sur le Steam Frame (un produit de réalité virtuelle tournant sous Linux et sur ARM), et permet d’hériter des tests déjà réalisés par Valve pour le Steam Frame.

En intégrant FEX, Hadron rend les jeux et autres logiciels indépendants de la volonté d’Apple d’abandonner la prise en charge de l’architecture x86.

Wine, l’implémentation libre des API Windows

On ne présente plus Wine, le logiciel libre qui permet de faire tourner depuis des décennies des programmes Windows sous Linux, BSD et macOS. En 2022 Arek Hiler avait prononcé la désormais célèbre phrase Win32 Is The Only Stable ABI on Linux, Win32 est la seule interface binaire de programmation qui soit stable sous Linux. Ce constat de l’ABI Win32 comme une interface très stable s’étend en fait bien au-delà des utilisateurs de Linux.

Wine est une brique fondamentale de Proton, la sous-couche de Valve pour faire tourner des jeux Windows sous Linux. Hadron fait de même pour macOS.

Hadron intègre donc FEX et Wine pour faire tourner des programmes Windows compilés pour x86 (32-bit et 64-bit) sur les macs exécutant macOS sur des processeurs ARM. L’héritage Wintel ne s’effacera donc jamais.

En intégrant Wine, Hadron rend les jeux et autres logiciels indépendants des interfaces de programmation de macOS.

Mesa, Zink et KosmicKrisp

Mesa est la collection de pilotes graphiques libres qui domine nos écosystèmes Linux et BSD. Mais Mesa propose aussi des pilotes pour d’autres plate-formes, comme Windows et macOS.

L’article Le pilote open-source Vulkan pour AMD “RADV” de chez Mesa bientôt disponible sous Windows ? posait ce constat en répondant à la question « Et pour Vulkan sur macOS ? » :

En participant au développement de RADV sous Linux et Windows, Valve se donne le pouvoir de contrôler la qualité de la pile logicielle d’exécution des jeux qu’ils vendent, jusqu’au pilote graphique inclus.

Pour macOS, la solution n’est pas à voir du côté de RADV (les derniers macs n’ont plus de cartes graphiques AMD de toute façon), mais du côté de MolktenVK et KosmicKrisp, des pilotes libres convertissant les appels Vulkan vers l’API Metal de macOS.

Sur macOS Vulkan est déjà disponible grâce à MoltenVK, une implémentation libre traduisant Vulkan pour l’API propriétaire Metal de macOS. Valve a investi dans MoltenVK. Cela permet par exemple à Valve de faire tourner leur jeu Dota2 sur macOS et pouvoir continuer à le vendre aux utilisateurs de macOS sans se soucier de l’obsolétisation d’OpenGL sur macOS par Apple.

KosmicKrisp est lui un pilote Mesa qui fait de même (convertir Vulkan vers Metal) mais de façon intimement spécialisée pour les puces AGX que l’on trouve dans les ordinateurs Apple M1, M2, etc. (aussi appelé « Apple Silicon »).

Et vous le voyez venir en mille, Hadron intègre KosmicKrisp pour fournir la prise en charge de l’API graphique Vulkan. KosmicKrisp traduit les appels Vulkan vers l’Interface de programmation (API) propriétaire Metal.

En intégrant KosmicKrisp, Hadron rend les jeux et autres logiciels indépendants de la politique d’Apple refusant de prendre en charge le standard industriel Vulkan.

Mais, et pour OpenGL ? Zink est un pilote Mesa qui implémente OpenGL au dessus de Vulkan, quel que soit le système (Zink tourne déjà sous Linux et Windows, et donc aussi macOS comme on peut le voir). Voilà, problème résolu.

En fait macOS fournit déjà OpenGL, mais ils l’ont déclaré obsolète depuis longtemps et ne fournissent qu’une ancienne version 4.1 qui date de 2010 (16 ans déjà !) qui est 7 ans plus ancienne que la dernière version d’OpenGL (4.6).

Zink implémente donc OpenGL 4.6 et en intégrant Zink, Hadron rend les jeux et autres logiciels indépendant de la volonté d’Apple d’abandonner OpenGL.

Et au passage, Zink propose la dernière version d’OpenGL et est un pilote désormais bien connu des développeurs de jeu, c’est tout bénef !

Hadron a comme politique de favoriser Zink à la place de l’implémentation OpenGL maison d’Apple. Quand un des bugs donnés comme exemple et affectant Unvanquished a été rapporté, l’expérimentation avait été réalisée avant que Hadron ne propose un moyen simple de lancer un logiciel en dehors de Steam, et donc l’expérimentation avait été faite en appelant Wine directement sans passer par le lanceur de Hadron. Le développeur Broyojo a constaté en lisant le journal du moteur de jeu Dæmon que dans ces circonstances, le jeu utilisait l’implémentation OpenGL d’Apple, chose qu’il s’est empressé de corriger fissa. Et pour le coup, ce changement est ce qui a corrigé le bug, trop facile.

L’article sur RADV et Windows indiquait :

Pour un distributeur de jeu vidéo comme Valve c’est excellent : ça signifie que — si nécessaire — le jeu peut être distribué avec RADV sur Windows et Linux pour les utilisateurs de cartes graphiques AMD, et MoltenVK ou KosmicKrisp sur macOS afin de fournir une expérience Vulkan finement contrôlée, et autres combinaisons sus-mentionnées. Cela permet de contrôler et donc d’assurer au maximum la compatibilité d’un jeu.

Nous y sommes. À part que cette fois-ci, ce n’est pas Valve qui en aurait eu l’initiative.

vkd3d-proton, DirectX 12 sur KosmicKrisp

Là où Zink implémente OpenGL sur Vulkan, vkd3d-proton fait de même et implémente DirectX 12 sur Vulkan, lui-même implémenté par KosmicKrisp.

DirectX 12 est l’interface de programmation graphique propriétaire de Microsoft pour Windows, elle est similaire à Metal et Vulkan.

Un développeur de jeu libre n’en a pas besoin : il peut utiliser OpenGL ou Vulkan, mais de très nombreux jeux utilisent Direct X 12, et Hadron s’assure donc de fournir cette prise en charge.

Comme son nom l’indique, vkd3d-proton est une brique essentielle de Proton, et l’est aussi maintenant pour Hadron.

mtld3d et DXMT, les plus anciens Direct3D sur Metal

Vous connaissez peut-être le logiciel DXVK qui implémentent Direct3D 8, 9, 10 et 11 au dessus de Vulkan. Vous aviez peut-être entendu parlé de D9VK qui faisait de même pour D3D9 mais qui est désormais intégré à DXVK, ou WineD3D qui implémentait Direct3D 8, 9, 10 et 11 au dessus de OpenGL.

Proton utilise DXVK sous Linux, implémentant donc D3D sur Vulkan, et Hadron pourrait faire de même, à la façon dont c’est effectivement implémenté avec vkd3d-proton.

Mais il existe deux logiciels qui implémentent D3D sur l’API Metal directement, ce qui permet de supprimer une couche intermédiaire de traduction.

Ces deux logiciels libres sont mtld3d qui implémente D3D9 sur Metal, et dxmt qui implémente D3D10 et D3D11 sur Metal.

Pour D3D8, Hadron ne précise pas si quelque chose est prévu, mais il devrait être possible d’utiliser DXVK, ou encore d3d8to9 qui implémente D3D8 sur D3D9. Et on peut supposer que rien ne devrait techniquement empêcher d’utiliser dd7to9 et autres projets de ce type (voir dxwrapper pour plus de détails).

Win32 + Vulkan + AMD64, la plate-forme universelle ?

Pour un développeur de logiciel libre, ces APIs DirectX sont peu utiles, mais tout le reste de cet écosystème peut profiter aux développeurs de logiciels libres.

Les compilateurs libres du projet MinGW permettent de compiler pour Win32. Wine permet de faire tourner ces programmes Win32 ailleurs que sur Windows. Et en s’appuyant sur les API graphiques OpenGL ou Vulkan, et des bibliothèques comme OpenAL ou SDL pour le son, le fenêtrage et les entrées, un développeur de jeu libre peut donc produire un seul binaire entièrement libre de la tête aux pieds qui tourne partout, sous Linux, BSD, macOS ou Windows.

Alors bien évidemment, certains préféreront un programme natif à leur système, avec de bonnes raisons. Mais quand un lanceur comme Steam ou une alternative libre comme Lutris fait toute l’intégration pour vous, tout ce qui retient se réduit à un attachement affectif (et ça compte beaucoup). C’est un chagrin légitime mais il n’empêche pas de jouer.

Wine fait déjà tourner naturellement les programmes x86 sur Linux et autres BSD. FEX peut être associé à Wine pour faire tourner des programmes Windows x86 sous Linux et macOS sur les processeurs ARM. Et Box64 sait faire de même sous Linux, non-seulement sur ARM64, mais aussi sur PowerPC (en mode petit-boutiste), RISC-V et Loongson.

Certains ont pu déclarer que « AMD64 is the new Java », en réalité, c’est peut-être la triforce Win32 + Vulkan + AMD64 qui est ce nouveau Java. Vous ferez peut-être autant la grimace, mais ça ne marche pas moins.

Et avec Hadron, votre prochain environnement de développement pour macOS pourrait simplement être MinGW, trop bien !

Avec Hadron, le futur de macOS court-circuite tout macOS, et Apple ne peut rien y faire.

Je vous présente Tenzu, un logiciel libre de gestion de projets qui propose des tableaux Kanban en ligne collaboratif. Tenzu veut offrir une expérience de collaboration moderne, tout en restant léger à faire tourner et à utiliser.

Tenzu est sous licence AGPLv3 et n'est pas open core. Nous fournissons des recettes de déploiement sous Docker-compose et Kubernetes. Nous avons également un SaaS dont les revenus reposent sur la contribution libre.

L'équipe derrière Tenzu est une petite coopérative française nommée Biru (bonjour !).

Tenzu, anciennement connu sous le nom de Taiga-Next, est le successeur de Taiga. L'objectif derrière Taiga a été d'encourager les bonnes pratiques dans la mise en place de l'agilité au sein d'une équipe tout en restant facile à prendre en main. Tenzu reprend cette philosophie avec un outil plus moderne, qui permet par exemple l'édition collaborative en temps réel.

Dans cette dépêche, nous allons revenir plus en détail sur ce que fait Tenzu à l'heure actuelle, la stack technique, la genèse du projet ainsi que nos plans pour la suite.

Sommaire

• Tenzu, c'est quoi ?
  • Description
  • Stack technique et licence
  • L'équipe
• Comment le projet est né
  • L’héritier de Taiga
  • Reprise de Taiga Next
  • Nouveau nom et transmission
  • Transformation de la boîte et démarrage
  • Modèle financier
• Hier, aujourd'hui et demain
  • Première version
  • Améliorations apportées en 2026
  • Roadmap

Tenzu, c'est quoi ?

Description

Tenzu est actuellement une alternative à Trello. Cet outil permet d'organiser son travail, de répartir les tâches et d'en faire le suivi.

Les fonctionnalités disponibles sont :

• Espaces de travail : le logiciel s'organise autour d'un découpage par espace de travail puis par projet
• Kanban : Créez vos tableaux kanban avec des statuts personnalisables
• Cartes : une interface d'édition de cartes (appelé "story" pour l'instant) riche avec édition collaborative temps réel, commentaires, pièces jointes, commentaires, et plus à venir rapidement !
• Un thème sombre et trois langues (français, anglais, espagnol) sont disponibles
• Tout ce qui relève des cycles de développement (type SCRUM) est encore en spécification, nous sommes preneurs de testeurs motivés !

Stack technique et licence

Tenzu est une application web SPA, écrite en Angular et Django. Elle utilise django-ninja pour construire l’API et, pour ajouter de la réactivité temps-réel, nous utilisons django-channels à base de Redis et de websockets. La base de données utilisée est en PostgreSQL et l’API REST est entièrement documentée sous le standard OpenAPI.

Concernant le déploiement, l’environnement de développement tourne sous Docker et des recettes docker-compose ainsi qu’un helm-chart pour les environnements Kubernetes sont fournis par l’équipe dans la doc technique. Le helm-chart proposé est également celui utilisé pour le déploiement du SaaS officiel.

L’intégralité du logiciel est sous licence AGPL v3 et garanti sans open core. Pour l’instant nous ne sommes pas ouverts aux contributions de code, faute de ressources qui nous permettraient de mettre en place et d’encadrer une politique de contribution claire. Le fork reste évidemment possible et l’ouverture aux contributions externes est un objectif que nous souhaitons atteindre dès lors que le projet aura un socle fonctionnel plus avancé.

L'équipe

Tenzu est développé par Biru, une coopérative française créée en 2024 est dont le développement de Tenzu est l'activité principale.

L'équipe est actuellement composée de trois personnes :

• Julie Rymer (c'est moi !), co-fondatrice et qui s'occupe principalement du développement backend ;
• Paul Guichon, co-fondateur qui s'occupe principalement du développement frontend et de l'administration système ;
• Marie Jubault-Bregler, associée et notre précieuse Product Designer.

L'équipe au complet qui expose pour la première fois en 2026

Comment le projet est né

L’héritier de Taiga

BIRU, l’entreprise derrière Tenzu, était au départ une ESN (Entreprise de Services du Numérique) qui faisait du développement à la demande d'applications web. En accord avec leurs convictions personnelles, Julie et Paul ont choisi de fonder Biru sous la forme d’une SCOP, une coopérative où chaque membre peut participer aux décisions stratégiques et où les bénéfices sont répartis équitablement. Très engagés dans le libre et l'opensource, l'objectif de Paul et Julie (les fondateurs) était, à terme, de pouvoir reverser une partie de leurs bénéfices à tous les outils libres qu'ils utilisent au quotidien au sein de l'entreprise et de transitionner dès que possible pour devenir eux-mêmes éditeurs opensource, en lieu et place de leur activité d'ESN.
Tenzu est d’abord né d’un projet interne visant à servir de bac à sable didactique à une nouvelle recrue sur les technologies de l'entreprise : Django et Angular. Le projet choisi était la réécriture du frontend de Taiga 6.

Taiga est un logiciel libre de gestion de projets pensé pour être léger, facile à prendre en main et encourageant les bonnes pratiques dans la mise en place de l'agilité au sein d'une équipe. Julie et Paul sont des utilisateurs de Taiga de longue date, notamment Paul, qui a commencé à le déployer dans son équipe dès sa sortie en 2014. Taiga, dans sa version 6 actuelle, est toujours maintenu par une entreprise qui en assure le support technique, mais n'évolue plus depuis des années. La stack technique, composée de Django 3 et d’AngularJS en CoffeeScript, est vieillissante, très difficilement reprenable, et cela se ressent de plus en plus sur le produit.

Quelques années plus tôt, l’équipe de Kaleidos, auteurs originels de Taiga, avait déjà commencé une réécriture, sous la forme du projet nommé Taiga Next. Plus moderne, repensée grâce à l'expérience de leur premier logiciel et avec un fort accent mis sur l'accessibilité, Taiga Next a suscité l'engouement de la communauté Taiga dont nous faisions partie.
Taiga Next était malheureusement resté au stade de pré-alpha depuis juillet 2023, et la communication se faisait absente depuis.

Le logo de Biru embraçant celui de Taiga Next

Reprise de Taiga Next

Au bout de quelques mois, le 19 avril 2024, notre propre projet de réécriture a bien avancé et nous décidons de contacter Kaleidos pour leur présenter notre travail et vérifier auprès d'eux qu'une future communication de notre part à son sujet ne les embêterait pas. Ils nous répondent rapidement pour nous apprendre qu'ils sont activement à la recherche de repreneurs pour Taiga Next.

Nous obtenons à ce moment là une confirmation de la raison de l’arrêt de l’activité sur Taiga Next : à peu près en même temps que celui-ci, Kaleidos se lance sur Penpot, un concurrent libre de Figma pensé pour permettre une collaboration sans heurt entre développeurs et designers. En plus d'offrir une alternative opensource, Penpot résout un véritable besoin non satisfait sur le marché et le projet décolle, avec des levées de fonds à la clé. Kaleidos doit se rendre à l'évidence : il leur est impossible de continuer à travailler sur les deux projets à la fois.

Le 5 juin 2024, après avoir longuement étudié la question, nous candidatons publiquement à la reprise du projet. Fin juillet cette candidature est validée et nous commençons à travailler à temps plein dessus. La transition d'ESN à éditeur opensource est arrivée bien plus vite que prévu, pour notre plus grand bonheur.

Nouveau nom et transmission

Plusieurs échanges permettent à l’équipe espagnole de confirmer que nous partageons ses idéaux. Nos deux entreprises tiennent à ce que Taiga Next reste opensource, inclusif et simple d'utilisation. Kaleidos (d'ailleurs également une ancienne ESN devenue éditrice opensource) nous cède la propriété intellectuelle sur le code de Taiga Next, nous accorde un financement pour démarrer le projet (100 000€) et nous accompagne dans la reprise. Cette générosité totalement désintéressée a fait hausser les sourcils de plus d'une personne à qui nous l'avons comté, à commencer par notre comptable et notre avocate !

Cette reprise s'accompagne d'un changement de nom et d'identité graphique afin de ne pas empiéter sur Taiga. Taiga Next devient alors Tenzu (après un bref détour par MotherShip/MotherSheep dont nous avons conservée l'idée pour le logo), en référence aux kanjis japonais 天図 qui signifient individuellement "carte" + "céleste". (Anecdote : BIRU vient lui du mot japonais ビール, bière). Ces mots reflètent notre ambition de construire un logiciel qui pourra guider naturellement ses utilisateurs.

Taiga Next devient Tenzu

Transformation de la boîte et démarrage

Ce changement entraîne aussi un renouvellement de l'équipe. En effet, l’entreprise quitte le modèle économique de l'ESN, c'est-à-dire la vente de prestations informatiques et technologiques, pour transitionner vers un fonctionnement type "startup" où l’équipe fabrique un produit et qui implique des profils de “builders”. La prise de risque et l’incertitude associées à ce changement ne conviennent pas à tous les caractères ni à toutes les situations de vie. Nous étions six dans l'équipe à ce moment-là ; nous sommes redescendus à trois dans les mois qui ont suivi pour arriver à l'équipe actuelle.

Modèle financier

Le modèle financier de Tenzu repose sur plusieurs offres :

1. Nous mettons à disposition un SaaS rémunéré par la contribution libre : chacun décide du montant qu’il ou elle souhaite nous reverser, y compris zéro. Ce modèle permet à chacun de participer à la hauteur de ses moyens et selon son utilisation de l'outil, sans engagement respectif.
2. Nous travaillons également avec des partenaires qui proposent du support, de l’hébergement, de l'infogérance ou encore de la formation pour celles et ceux qui voudraient être accompagnés dans leur utilisation de Tenzu.

Aujourd’hui encore, nos revenus viennent uniquement des contributions et des subventions reçues pour ce projet.
Tenzu n'est pas gratuit, d'ailleurs aucun projet opensource ne l'est, mais nous avons choisi un modèle de financement qui convient à nos valeurs et nos ambitions.

Hier, aujourd'hui et demain

Première version

Notre ambition est claire : nous allons reprendre les fonctionnalités principales de Taiga en les améliorant en termes d’interface et d’expérience utilisateur, tout en conservant sa légèreté et sa simplicité. Nous avons pour objectif d’atteindre le plus rapidement possible un nombre d’utilisateurs qui nous permette de vivre de notre travail.

Nous sommes repartis de la dernière version de Taiga Next. Nous avons conservé en grande partie le backend existant mais avons dû repartir de zéro pour le frontend.

Le 30 octobre 2024, la première bêta de Tenzu sort sous la forme d'une démo en ligne, avec la mise à disposition de son code source. Nous y avons intégré les fonctionnalités cœur du logiciel : le multi-Kanban, les stories et les espaces de travail.
Le 4 mars 2025, nous sortons la documentation avec des recettes et toutes les explications nécessaires pour faire tourner Tenzu chez soi.

Le 30 septembre 2025, exactement 11 mois après la sortie de la démo, la première version stable de Tenzu sort. L’intégration du SSO ainsi que l’ajout de commentaires arrivera très vite par la suite.
Notre SaaS sera hébergé par IndieHosters, une autre coopérative impliquée dans le libre, rencontrée via le réseau Libre Entreprise et qui a choisi de participer à l'aventure.

Améliorations apportées en 2026

De gros chantiers ont été finalisés en 2026, à commencer par l’écriture collaborative.
L’éditeur existant n’a pas changé en apparence, mais désormais, lorsque deux personnes ouvrent en même temps une même story, elles voient l’avatar de l’autre apparaître et un curseur individuel dans le champ de description leur permet de suivre en temps réel toutes les modifications apportées.

Puis est arrivée la possibilité d’importer vos projets depuis Taiga. Vous pouvez désormais récupérer vos projets et leurs rôles, ainsi que le contenu de vos Kanbans avec vos statuts, stories, commentaires et pièces jointes, ainsi que réinviter automatiquement vos utilisateurs !

Un fil d'actualité a également été ajouté pour permettre d’annoncer les nouvelles versions, les maintenances et poser d’éventuelles questions aux utilisateurs.
Le design system a été complètement revu, du point de vue de l’interface comme de la technique, pour apporter plus de simplicité et d’accessibilité. C’est un premier pas vers un système de configuration dynamique du thème qui permettra aux utilisateurs de personnaliser leur expérience.

Enfin, nous avons très récemment ajouté un système de tags afin d’enrichir et catégoriser vos stories.

Roadmap

Nous continuons de travailler sur plusieurs chantiers :

• Permettre l’ajout de davantage de méta-informations sur les stories ;
• La mise en place d’une barre de recherche et de filtres ;
• La traduction communautaire, pour ajouter de nouvelles langues ;
• L’exportation de vos données au format JSON.

Et rapidement nous allons mettre en place les cycles de développement de type SCRUM, le deuxième module majeur de Taiga et celui qui lui a permis de conquérir le cœur de ses utilisateurs face à la concurrence.

Tenzu a bientôt deux ans et nous continuons de le faire évoluer avec passion. Ancien utilisateurs de Taiga aguerris ou nouveaux venus, nous vous souhaitons la bienvenue à la découverte de notre aventure.