Zedless : un fork de Zed axé sur la confidentialité et le local-first

 (github.com/zedless-editor)
5 points par GN⁺ 2025-08-21 | 1 commentaires | Partager sur WhatsApp
  • Zedless est un fork basé sur l’éditeur open source Zed, mettant l’accent sur la protection de la vie privée et un environnement local-first
  • Zedless supprime les dépendances au cloud et permet aux utilisateurs de configurer directement l’infrastructure de leur choix
  • Toutes les fonctionnalités de spyware et de télémétrie à distance doivent être supprimées
  • Adoption d’une politique sans réattribution des droits d’auteur des contributeurs (No CLA), de sorte que tous les développeurs conservent leurs droits
  • Utilisation d’outils supplémentaires pour l’automatisation de la gestion des licences et la conformité aux licences open source

Présentation de Zedless

  • Zedless est un fork de l’éditeur de code Zed, visant à garantir la confidentialité des utilisateurs et à privilégier avant tout l’utilisabilité en environnement local
  • Le projet est actuellement en cours de développement et accepte librement les contributions externes

Principaux changements prévus

  • Suppression des dépendances aux services cloud impossibles à auto-héberger
    • Les composants et fonctionnalités strictement dépendants d’un cloud tiers sont destinés à être supprimés
  • Suppression des spyware et protection des données
    • La télémétrie et les systèmes automatiques de rapport de crash font tous partie des éléments à retirer
  • Prise en charge prioritaire de l’infrastructure utilisateur
    • Lors de l’utilisation de fonctionnalités de services réseau, l’utilisateur peut spécifier directement son fournisseur de services dans un format standard
    • Il n’existe pas de liste de « fournisseurs par défaut », et cette fonctionnalité est désactivée par défaut
  • Aucune cession de droits d’auteur
    • Les participants au projet conservent leurs droits d’auteur
    • Application d’une politique No rugpulls afin d’éviter tout préjudice pour les développeurs

Gestion des licences et des dépendances

  • La fourniture des informations de licence pour les dépendances tierces est obligatoire, et l’outil cargo-about est utilisé à cette fin
  • Points d’attention
    • Si l’erreur 'no license specified' se produit sur une crate que vous avez écrite, il faut ajouter publish = false dans Cargo.toml
    • Si une erreur survient parce que les exigences de licence d’un paquet dépendant ne sont pas respectées, il faut vérifier et indiquer la compatibilité de la licence concernée
    • Si cargo-about ne parvient pas à trouver la licence d’une dépendance, il faut ajouter au script un élément d’explication explicite

Importance du projet

  • Zedless constitue une alternative particulièrement intéressante, du point de vue de la stabilité, de l’autonomie et de la protection juridique, pour les utilisateurs et les équipes qui accordent de l’importance à la confidentialité et à un environnement de développement centré sur le local
  • Par rapport à Zed, il écarte résolument les services cloud propriétaires et les fonctions de suivi à distance, qui peuvent représenter des failles de sécurité potentielles, permettant ainsi de bâtir une fiabilité fondée sur sa propre infrastructure et sur l’écosystème open source

À lire aussi

1 commentaires

 
GN⁺ 2025-08-21
Avis Hacker News
  • Je suis content de voir ce genre d’initiative autour de Zed ; ce n’est pas encore parfait aujourd’hui, mais c’est prometteur pour la suite. En revanche, je ne veux absolument pas de fonctionnalités d’IA ni de télémétrie. Ces derniers temps, j’utilise à peine les fonctions d’IA dans les éditeurs. J’ai essayé plusieurs fois, y compris Copilot, mais ça ne me satisfait toujours pas. Ce type de fonctionnalités me semble plus adapté à d’autres étapes de la chaîne de développement logiciel, par exemple la revue de code ou l’aide à la documentation. Je serais prêt à payer pour un service de synchronisation des paramètres ou sous forme d’abonnement de maintenance. Mais je ne pense pas qu’un outil comme un éditeur soit un produit capable d’offrir le ROI qu’attendent les VC. D’ici un an, je reviendrai peut-être au duo Emacs + IntelliJ.
    • Heureux de voir enfin ce genre d’avis. Pendant que beaucoup encensaient les éditeurs IA, je me sentais un peu isolé en ne comprenant pas pourquoi tout le monde s’emballait autant. J’en ai testé quelques-uns, mais je n’ai jamais eu l’impression que mon workflow s’améliorait. Du point de vue de notre équipe, l’écriture du code n’est pas le goulot d’étranglement ; c’est plutôt la revue de code qui n’avance pas assez vite. On envisage donc d’introduire de la revue de code assistée par IA pour alléger une partie de la charge.
    • Dans Zed, on peut désactiver les fonctions d’IA : Blog Zed : désactiver les fonctionnalités d’IA
    • Si Zed arrêtait d’ajouter des fonctions d’IA et se concentrait sur l’édition de texte, ça pourrait vraiment devenir un excellent produit.
    • Il ne suffit pas simplement de ne pas utiliser, ou de désactiver, l’IA et la télémétrie ? Ce n’est pas comme si on les imposait sous vos yeux. Ce serait mieux si la télémétrie était désactivée par défaut, mais si on peut la couper facilement, ça me va.
    • On voit souvent sur HN ou sur les forums geeks des gens dire qu’ils paieraient pour un abonnement de maintenance, mais dans la réalité ces utilisateurs sont trop peu nombreux pour suffire à rendre un produit ou une entreprise viable sur la durée.
  • J’ai toujours des sentiments mitigés envers les forks, surtout quand il s’agit de hard forks. Zed a récemment ajouté la possibilité de désactiver toutes les fonctions d’IA, et la télémétrie est désactivable via opt-out, donc je ne sais pas s’il y a vraiment besoin d’un fork. Quand on regarde la liste des fonctions proposées, ce sont des éléments qui pourraient largement être remontés dans le projet principal comme fonctionnalités de base. J’espère que ce sera le cas. J’ai encore en tête la fragmentation de l’écosystème après des forks comme celui de Redis.
    • Les développeurs de Zed montrent déjà des signes un peu suspects, par exemple en ne permettant pas de désactiver la fonctionnalité de compte / connexion Zed, donc je pense que la nécessité d’un fork n’est pas négligeable. Je ne vois pas de raison d’avoir peur d’une fragmentation de l’écosystème. Au contraire, le fait que différents outils coexistent me semble une voie positive pour échapper au lock-in et à la pensée de groupe.
    • Même une télémétrie en opt-in reste inconfortable. Je n’arrive pas à me débarrasser de l’idée que le logiciel pourrait à tout moment rapporter jusqu’à ma taille de sous-vêtements ou le contenu de mon petit-déjeuner. Le fait de dépendre d’une seule case à cocher me met mal à l’aise. Et pour d’autres fonctions, devoir choisir « pas besoin » à chaque fois dans un modèle d’opt-out est pénible. En règle générale, je préfère le minimalisme.
    • Comme Zed est déjà open source, je pense que le besoin d’un fork est limité. Donc si Zed passait par défaut toutes ses fonctionnalités en opt-in, l’intérêt même d’un tel fork disparaîtrait.
    • Ce serait bien d’avoir une garantie supplémentaire qu’il n’y aura absolument aucun envoi en arrière-plan au premier lancement. Pour information, j’utilise aussi opensnitch en complément, en défense à deux niveaux.
  • Cette annonce de fork me semble un peu précipitée, surtout sans manifeste expliquant dans quel but il est créé. En voyant la formule « no rugpulls », on a l’impression qu’il s’est passé quelque chose côté Zed, alors que tous les lecteurs de HN ne suivent pas forcément en permanence ce type de débat open source.
    • Le Contributor Agreement (CA) est un mécanisme qui attribue tous les droits d’auteur à l’entreprise afin de se prémunir contre un éventuel changement de licence ultérieur, ce qu’on appelle parfois un « license rugpull ». Le fait que Zed exige un CA signifie aussi qu’ils gardent à l’esprit une possible évolution future de la licence.
    • Zed était déjà bien connu au départ comme un projet centré sur le cloud et l’IA. Je pense que c’est là la motivation claire du fork. Ce n’est pas vraiment une nouvelle controverse ou un incident soudain ; c’est plutôt une orientation clairement assumée, qui déplaît à beaucoup.
    • Je pense que ce fork a été déclenché par cette discussion GitHub.
    • Zed a levé de l’argent auprès de VC. À partir de là, un fork axé sur la confidentialité et le local-first se justifie déjà par le simple fait que ces aspects manquent. Il faudra probablement retirer beaucoup des fonctionnalités mises en avant par Zed, mais parler de rugpull me paraît un peu discutable.
  • Liste de fils de discussion associés
  • Je suis curieux de voir ce que ce fork va produire. Ça me rappelle comment IO.js, autrefois fork de node.js, avait fini par infléchir l’évolution de node. À une époque où la télémétrie et l’IA sont imposées partout, cela rappelle aussi qu’il existe une communauté de développeurs sensible à ce genre de sujets.
  • Ce que j’aimerais vraiment dans Zed, c’est le support multi-fenêtres. Impossible d’afficher le panneau agent ou d’autres panneaux sur un autre écran. L’orientation local-first me plaît aussi, mais comme j’utilise également des outils d’IA, je ne pense pas adopter ce fork tout de suite. Cela dit, une direction sans télémétrie et sans Contributor Agreement est bienvenue. J’aime l’idée de ce fork et je lui souhaite bonne chance. J’ai très bien utilisé Zed pendant plus d’un an sans ses fonctions d’IA, donc si un jour je me lasse de l’IA, je finirai peut-être par migrer vers ce fork.
    • Même expérience pour moi. Après avoir vu tant de débats autour de Zed, je l’ai installé, mais comme on ne pouvait pas détacher les panneaux ni même modifier certains réglages de base laissés sans correction depuis plus d’un an, je l’ai tout simplement désinstallé.
  • Je me doutais qu’un tel fork finirait bien par apparaître un jour. J’ai même envisagé de le lancer moi-même, mais j’ai abandonné à cause de la charge de maintenance. J’avais aussi pensé au nom zim (zed improved, comme vim). Je suis content de voir que le projet existe réellement.
  • Commentaire de l’auteur : texte original sur Lobsters, accéder directement au projet fork. Je retire progressivement la télémétrie, les mises à jour automatiques, les intégrations d’IA réservées au cloud, les dépendances à node.js, le téléchargement automatique des serveurs de langage, les incitations à l’achat supplémentaire, les boutons de connexion et d’autres éléments que je considère inutiles pour moi. Mon objectif est aussi, si possible, de rendre auto-hébergeables les fonctionnalités cloud-only de Zeta edit (par exemple exécuter les prédictions de Zeta edit sur une instance llama.cpp ou vLLM). Dans son état actuel, le projet est suffisamment fonctionnel pour servir d’éditeur principal. Mais comme les changements de code sont nombreux, il y a une limite à ce qu’on peut faire pour éviter les conflits de fusion. J’expérimente donc aussi des modifications automatiques au niveau de l’AST à l’aide de tree-sitter. Cette expérimentation pourrait évoluer en un outil permettant de créer une version « personnalisée et débarrassée de ses défauts » de Zed.
    • J’aimerais poser une question sur la dépendance à node.js : à partir de quand les gens ont-ils commencé à ne plus aimer node, et pour quelles raisons ?
  • Je me demande si, pour ce genre de fork, une simple pull request suffirait en pratique à masquer les fonctions d’IA de Zed derrière un compile flag. Sans aller jusqu’au « fork », est-ce qu’on ne pourrait pas produire le même Zed sans IA avec le même code, simplement en changeant la commande de build ?