Le pacte

Le logiciel libre tourne sur deux transactions à sens unique. Les utilisateurs prennent le produit sans rien donner en retour, parce que trois siècles de marché nous ont appris qu’une chose téléchargeable à l’infini n’a pas de prix. Les développeurs décident sans répondre à personne, parce que la licence dit qu’ils ne doivent rien — pas même une explication. D’un côté on prend sans payer, de l’autre on règne sans rendre de comptes. Ce ne sont pas deux problèmes : c’est le même, vu de ses deux bouts, et l’essentiel de ce qui ne va pas dans le logiciel libre pousse dessus.

Ansel refuse les deux moitiés. Quand des gens dépendent d’un outil pour accomplir leur travail — des années d’apprentissage, des bibliothèques entières de retouches, parfois un gagne-pain —, une responsabilité existe, qu’on le veuille ou non. Et elle ne peut pas être acquittée par les seules promesses techniques : garder les anciennes retouches lisibles pour toujours est nécessaire, mais un projet peut honorer ses formats de fichiers et trahir quand même les gens qui produisent les fichiers. Cette page énonce explicitement les deux sens du contrat. Elle est écrite pour être opposable : si le projet rompt un engagement ci-dessous, citez-la-nous — elle est faite pour ça.

Pourquoi ce pacte existe

Ansel a été forké de Darktable 4.0 en mai 2022, et le fork n’était pas un désaccord technique : c’était le refus de continuer à travailler dans un ensemble de défaillances organisationnelles qu’aucune quantité de code ne pouvait réparer. Ces défaillances sont documentées — mesurées sur le registre public, archives en main, dans La conception et l’ingénierie malgré l’open-source  — et ce pacte en est la négation point par point. Les énoncer explicitement n’est pas un règlement de comptes : un projet qui ne nomme pas les erreurs qu’il a fuies n’a aucun moyen de se voir en train de les répéter.

1. Des fonctionnalités sans problèmes. Des refontes ambitieuses livrées sans problème énoncé, sans utilisateur défini, sans critères d’acceptation — servant le plaisir de construire plutôt que les besoins de la base. D’où : les problèmes avant les fonctionnalités, et un protocole de conception qui refuse les solutions tant que le problème n’est pas cadré.
2. L’ambition qui s’arrête à la livraison. Personne ne chiffrait ce qu’une fonctionnalité coûterait à maintenir ; le code neuf était tissé à travers l’ancien au lieu d’être enclos, jusqu’à ce que les bugs d’interface ne puissent plus être rattachés à des causes. D’où : la maintenance avant la nouveauté, et l’enclosure comme critère d’acceptation.
3. Un veto jamais exercé. La seule règle écrite — ne jamais empêcher quelqu’un de coder quand il s’amuse — rendait le refus culturellement impossible : presque tout était fusionné, sans concertation, et la dette technique était reconnue en public et payée par personne. D’où : des critères d’acceptation écrits, et le refus comme un devoir dû aux utilisateurs.
4. Le capital des utilisateurs traité comme jetable. Des chaînes de travail, des habitudes acquises et des installations qui marchaient, cassées version après version, des régressions requalifiées en choix de conception, et le récit que l’utilisateur fait de sa propre expérience réécrit à sa place. D’où : votre capital est intouchable, et votre témoignage est souverain.
5. Le registre réduit au silence au lieu de recevoir des réponses. Des signalements laissés sans lecture et balayés par un robot, des testeurs chassés par le silence, la critique requalifiée en toxicité et modérée sur le ton pendant que son fond restait sans réponse. D’où : pas de robot de péremption (signaler les bugs), et un code de conduite dont la première section protège la critique avant de protéger le confort de quiconque.
6. Le pouvoir sans structure. Ni mandat, ni terme, ni appel — les décisions tenues par qui tenait les droits de fusion et les outils de modération, et la solitude du mainteneur racontée comme un héroïsme au lieu d’être traitée comme un défaut d’organisation. D’où : des raisons données, des décisions susceptibles d’appel, les mêmes règles pour tous, et cette constitution écrite elle-même.

Rien de tout cela n’exige de croire la version du fork : chaque erreur ci-dessus est énoncée pour qu’Ansel puisse être vérifié contre elle. Le jour où ce projet livre des fonctionnalités sans problèmes, fusionne sans refuser, casse vos retouches, fait taire son registre ou modère ses critiques sur le ton — citez cette page.

Ce que le projet doit à ses utilisateurs

1. Votre capital est intouchable. Vos données, vos historiques de retouche, votre chaîne de travail apprise sont des années de votre vie. Aucune version ne les détruira : les anciennes retouches restent lisibles et reproduisent le même résultat, et les changements qui les casseraient sont confinés aux versions majeures, annoncées comme telles.
2. Les problèmes avant les fonctionnalités. Le travail part d’un problème que quelqu’un a réellement, énoncé et cadré avant qu’aucune solution ne soit discutée (le protocole de conception). Aucune fonctionnalité n’entre parce que ce serait cool, parce qu’un autre logiciel l’a, ou parce qu’elle était amusante à écrire.
3. La maintenance avant la nouveauté. L’essentiel du coût d’une fonctionnalité vient après sa livraison. Ce que nous ne pouvons pas maintenir avec les ressources actuelles sera refusé ou retiré — le refus n’est pas de l’hostilité, c’est l’outil qui reste digne de confiance. La réponse « non, parce que nous ne pourrions pas le maintenir » est une promesse tenue, pas une porte claquée. Une grande partie du fardeau de maintenance tient à la prise en charge de 3 plateformes (Windows, Linux et MacOS), qui doit se faire avec le moins possible d’heuristiques et de paradigmes idiomatiques propres à chaque plateforme.
4. Votre témoignage est entendu ; vos prescriptions ne le sont pas. Vous êtes la seule autorité sur vos buts, votre contexte et vos douleurs — personne ne réécrira votre expérience à votre place, ni ne vous dira que ce que vous avez rencontré « n’est pas un bug, c’est un choix de conception » pour clore la discussion. La décision sur les solutions reste à ceux qui répondent de leur maintenance ; les raisons d’une décision sont énoncées, et les décisions sont réversibles tant que l’usage réel ne les a pas validées.
5. Vous ne serez pas blâmé pour la complexité de l’outil. Deux difficultés ne doivent pas être confondues. Ansel attend de vous la maîtrise de votre métier — la couleur, les appareils, la lumière (portée) — et documente sa théorie précisément parce qu’elle doit s’apprendre : être renvoyé au bon chapitre sur une question de métier est une aide légitime, et apprendre fait partie du contrat que vous avez accepté en choisissant cet outil. L’outil lui-même est une autre affaire : quand vous ne parvenez pas à trouver, comprendre ou actionner ce que les conventions standards d’interface devraient rendre évident, vous avez trouvé un défaut de conception ou de documentation de notre côté, pas une faute personnelle du vôtre. Le métier peut exiger un manuel ; l’outil ne le doit pas — et savoir duquel des deux relève votre question se juge sur la question, jamais sur vous.
6. L’outil est documenté pour ce qu’il vous fait à vous, pas seulement pour vous — ses hypothèses, ses limites, ses coûts en temps d’apprentissage, pas seulement ses fonctionnalités.
7. Le prospectus reste honnête. Ce qu’Ansel est et n’est pas est écrit dans la Portée, et les demandes sont jugées contre elle — jamais contre l’humeur du jour. Si le projet dérive de ses valeurs déclarées, cette page est la pièce à lui opposer.

Ce que le projet demande à ses utilisateurs

1. Signalez les problèmes comme un témoignage. Ce que vous avez fait, ce qui s’est passé, ce que vous attendiez, dans vos mots et dans votre langue — en suivant la culture de résolution de problèmes. Vous ne devez rien de plus technique que cela ; la traduction en causes et en solutions est notre travail, pas le vôtre.
2. Acceptez le périmètre. Ansel est un outil avec une portée. Une demande hors de cette portée sera refusée, portée citée à l’appui — ce refus est légitime, et répéter la demande ne la fera pas avancer. « Faites-en un Lightroom gratuit » est un souhait, pas un grief.
3. Respectez les conditions de travail. Vous êtes nombreux et nous sommes peu. L’insistance, les déferlements collectifs et les ultimatums sont de la pression sur des gens non payés ; un signalement clair vaut mieux que dix rappels. L’absence de réponse veut dire « pas encore possible », jamais « vous ne comptez pas ».
4. Rendez ce que vous pouvez. Testez les versions de développement, confirmez les corrections, améliorez la documentation, répondez à un autre utilisateur, financez le travail. Le projet répond de vos besoins ; les conditions de travail de ceux qui le font sont, en retour, en partie votre responsabilité — c’est cela, le pacte.

Ce que les contributeurs doivent, et ce qu’ils reçoivent

1. L’entrée est déclarée. Ce que le projet attend que vous sachiez est écrit avant que vous n’investissiez : la portée, le protocole de conception, le style de code. Personne ne devrait découvrir les règles en les enfreignant.
2. L’autorité suit le travail démontré, dans un périmètre borné. La confiance croît avec le dossier : un nouveau venu décide dans une zone petite et enclose ; le périmètre s’élargit à mesure que le dossier s’étoffe. Le volume et le ton ne rapportent rien ; l’amélioration vérifiable du projet — code, documentation, tests, assistance — rapporte tout.
3. L’apprentissage se fait hors de la production. Les expériences vivent dans des branches et des prototypes, pas dans l’outil avec lequel des gens travaillent. Le projet vous doit une revue honnête et du mentorat dans la limite de ses capacités ; il ne vous doit pas une fusion.
4. Chaque fonctionnalité est une dette de maintenance, et son auteur en est le premier mainteneur. Une contribution s’évalue à ce qu’elle coûtera à garder en vie, pas à ce qu’elle a coûté à écrire. « Ça marche » n’est pas la barre ; « quelqu’un d’autre peut le réparer » l’est.
5. Les refus viennent avec des raisons, et les décisions avec un appel. Une contribution rejetée est mesurée à des critères écrits que vous pouvez contester avec des preuves. L’exclusion — de code ou de personnes — est bornée, notifiée et susceptible d’appel (code de conduite) ; elle protège le collectif, elle ne punit pas une personne.

Les limites honnêtes de ce pacte

Aujourd’hui, Ansel est maintenu par une personne, aidée. Les engagements ci-dessus sont tenus par cette personne, c’est-à-dire tenus dans des limites humaines : la capacité, la santé et le financement décident du rythme, et les priorités sont publiques plutôt que négociées au cas par cas. Le pacte n’est pas un contrat de niveau de service ; c’est une déclaration de valeurs assez précise pour être vérifiée. La structure de long terme que vise ce projet — où utilisateurs et travailleurs partagent la propriété et le vote, où ces engagements sont tenus par une institution plutôt que par un homme — est décrite dans le livre La conception et l’ingénierie malgré l’open-source . D’ici là, cette page est le contrat, et le registre est public : tenez-nous-y.