Zedless: Ein Zed-Fork mit Fokus auf Privatsphäre und Local-First

 (github.com/zedless-editor)
5 Punkte von GN⁺ 2025-08-21 | 1 Kommentare | Auf WhatsApp teilen
  • Zedless ist ein Fork des Open-Source-Editors Zed und legt den Schwerpunkt auf Schutz der Privatsphäre und eine Local-First-Umgebung
  • Zedless entfernt Cloud-Abhängigkeiten und ermöglicht es Nutzern, ihre gewünschte Infrastruktur selbst zu konfigurieren
  • Spyware- und Remote-Telemetrie-Funktionen sollen vollständig entfernt werden
  • Mit einer No-CLA-Richtlinie (keine Neuzuweisung von Urheberrechten für Contributor) behalten alle Entwickler ihre Urheberrechte
  • Für automatisiertes Lizenzmanagement und die Einhaltung von Open-Source-Lizenzen werden zusätzliche Tools eingesetzt

Einführung in Zedless

  • Zedless ist ein Fork des Code-Editors Zed und zielt darauf ab, die Privatsphäre der Nutzer sowie eine lokale Umgebung mit höchster Priorität bei der Nutzbarkeit sicherzustellen
  • Das Projekt befindet sich derzeit in Entwicklung und nimmt externe Beiträge offen entgegen

Geplante Hauptänderungen

  • Entfernung der Abhängigkeit von nicht selbst hostbaren Cloud-Diensten
    • Komponenten und Funktionen, die strikt von Drittanbieter-Clouds abhängen, sollen entfernt werden
  • Entfernung von Spyware und Datenschutz
    • Telemetrie und automatische Crash-Reporting-Systeme sollen vollständig entfernt werden
  • Vorrangige Unterstützung für Nutzerinfrastruktur
    • Bei der Nutzung von Netzwerkdiensten können Nutzer den Service-Provider selbst in einem Standardformat angeben
    • Es gibt keine Liste mit „Standardanbietern“, und diese Funktion ist standardmäßig deaktiviert
  • Keine Abtretung von Urheberrechten
    • Projektteilnehmer behalten ihre Urheberrechte
    • Es gilt eine No-rugpulls-Richtlinie, damit Entwickler nicht benachteiligt werden

Lizenz- und Abhängigkeitsmanagement

  • Die Bereitstellung von Lizenzinformationen für Third-Party-Abhängigkeiten ist verpflichtend; dafür wird das Tool cargo-about verwendet
  • Hinweise
    • Wenn im eigenen Crate der Fehler „no license specified“ auftritt, muss in der Cargo.toml publish = false ergänzt werden
    • Wenn ein Fehler wegen nicht erfüllter Lizenzanforderungen von Abhängigkeiten auftritt, müssen Eignung und Angabe der jeweiligen Lizenz geprüft werden
    • Wenn cargo-about die Lizenz einer Abhängigkeit nicht finden kann, muss dem Skript ein Eintrag mit einer klaren Erklärung hinzugefügt werden

Bedeutung des Projekts

  • Zedless ist insbesondere für Nutzer und Teams, die Privatsphäre und eine lokal ausgerichtete Entwicklungsumgebung wichtig finden, eine hervorragende Alternative in Bezug auf Stabilität, Autonomie und rechtlichen Schutz
  • Im Vergleich zum bestehenden Zed werden potenzielle Sicherheitsrisiken wie proprietäre Cloud-Dienste und Remote-Tracking-Funktionen konsequent ausgeschlossen, wodurch sich auf Basis eigener Infrastruktur und des Open-Source-Ökosystems Vertrauenswürdigkeit aufbauen lässt

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-08-21
Hacker-News-Kommentare
  • Ich freue mich über diese Entwicklung rund um Zed. Es ist derzeit noch nicht perfekt, aber ich bin gespannt, wohin es sich entwickelt. AI- und Telemetrie-Funktionen will ich allerdings überhaupt nicht. In letzter Zeit nutze ich AI-Funktionen in Editoren kaum noch. Ich habe Dinge wie Copilot mehrfach ausprobiert, bin aber bis heute nicht wirklich zufrieden. Solche Funktionen passen meiner Meinung nach eher an andere Stellen in der Softwareentwicklungs-Pipeline, etwa in Code-Reviews oder als Unterstützung bei der Dokumentation. Für einen Einstellungs-Sync-Dienst oder ein Wartungs-Abo würde ich durchaus bezahlen. Aber ich glaube nicht, dass ein Editor als Werkzeug ein Produkt ist, das den von VCs gewünschten ROI liefern kann. Vielleicht bin ich in einem Jahr wieder bei meiner Kombination aus Emacs und IntelliJ.
    • Ich bin froh, so eine Meinung endlich zu lesen. Während viele AI-Editoren loben, habe ich mich eher ausgeschlossen gefühlt, weil ich den großen Hype nicht wirklich nachvollziehen konnte. Ich habe einige AI-Editoren ausprobiert, aber nie erlebt, dass mein Workflow dadurch besser wurde. Bei unserem Team liegt das vielleicht daran, dass das Schreiben von Code nicht der Engpass ist, sondern eher, dass Code-Reviews nicht schnell genug vorankommen. Deshalb überlegen wir, AI-Code-Review einzuführen, um einen Teil dieser Last zu verringern.
    • In Zed kann man AI-Funktionen deaktivieren: Zed-Blog: AI-Funktionen deaktivieren
    • Zed könnte ein wirklich großartiges Produkt werden, wenn es aufhören würde, AI-Funktionen einzubauen, und sich stattdessen auf Textbearbeitung konzentriert.
    • Reicht es nicht, AI- oder Telemetrie-Funktionen einfach gar nicht zu verwenden oder auszuschalten? Sie werden einem ja nicht direkt ins Gesicht gedrückt. Bei Telemetrie wäre standardmäßig AUS natürlich noch besser, aber wenn man sie einfach deaktivieren kann, ist das für mich okay.
    • Solche Aussagen, dass man für ein Wartungs-Abo zahlen würde, liest man in vielen HN- oder Geek-Foren oft, aber in der Praxis gibt es nur wenige solche Nutzer, und das reicht nicht aus, um ein Produkt oder ein Unternehmen dauerhaft tragfähig zu machen.
  • Bei Forks habe ich immer gemischte Gefühle, besonders bei Hard Forks. Zed hat kürzlich die Möglichkeit hinzugefügt, alle AI-Funktionen zu deaktivieren, und auch Telemetrie ist per Opt-out abschaltbar. Deshalb bin ich mir nicht sicher, ob überhaupt ein Fork nötig ist. Wenn man sich die vorgeschlagene Funktionsliste ansieht, wirkt vieles so, als könnte es problemlos als Standardfunktion in das Hauptprojekt upstreamen. Ich hoffe, dass genau das passiert. Ich erinnere mich auch daran, wie sich das Ökosystem beim früheren Redis-Fork aufgespalten hat.
    • Die Zed-Entwickler zeigen bereits ein paar etwas fragwürdige Tendenzen, etwa dass sie das Deaktivieren von Zed-Konto-/Login-Funktionen nicht erlauben. Deshalb halte ich die Notwendigkeit eines Forks nicht für gering. Ich denke auch nicht, dass man Angst vor einer Spaltung des Ökosystems haben muss. Im Gegenteil: Dass verschiedene Werkzeuge nebeneinander bestehen, ist eher ein positiver Weg, um sich von Lock-in und Gruppendenken zu lösen.
    • Selbst Telemetrie im Opt-in-Verfahren fühlt sich für mich immer noch unangenehm an. Ich werde das Bewusstsein nicht los, dass die Software theoretisch jederzeit sogar meine Unterwäschengröße oder mein Frühstück melden könnte. Sich dabei auf genau ein einziges Kontrollkästchen zu verlassen, fühlt sich ebenfalls unsicher an. Auch bei anderen Funktionen ist das lästig, wenn man jedes Mal wieder „brauche ich nicht“ per Opt-out auswählen muss. Insgesamt bevorzuge ich Minimalismus.
    • Ich denke, ein Fork ist schon deshalb weniger nötig, weil Zed bereits Open Source ist. Wenn Zed standardmäßig alle Funktionen auf Opt-in umstellen würde, würde der Existenzgrund für so einen Fork verschwinden.
    • Es wäre gut, eine zusätzliche Garantie zu haben, dass beim ersten Start absolut nichts im Hintergrund hochgeladen wird. Zur Sicherheit lasse ich übrigens zusätzlich noch opensnitch laufen.
  • Diese Fork-Ankündigung wirkt etwas früh, vor allem ohne ein Manifest, das erklärt, zu welchem Zweck überhaupt geforkt wird. Wenn man den Ausdruck „no rugpulls“ sieht, wirkt es so, als wäre bei Zed irgendein Vorfall passiert, aber nicht alle HN-Leser sind in solchen Open-Source-Debatten ständig voll im Thema.
    • Eine Contributor Agreement (CA) ist ein Mechanismus, mit dem alle Urheberrechte an ein Unternehmen übertragen werden, um sich später die Möglichkeit eines sogenannten „Lizenz-Rugpulls“ durch eine Lizenzänderung offenzuhalten. Dass Zed eine CA verlangt, bedeutet auch, dass man die Möglichkeit einer künftigen Lizenzänderung im Blick hat.
    • Zed war ursprünglich bereits gut als Cloud- und AI-zentriertes Projekt bekannt. Ich denke, genau das ist die klare Motivation hinter diesem Fork. Es geht weniger um eine plötzlich neu entstandene Kontroverse oder einen einzelnen Vorfall, sondern um eine Richtung, die deutlich erkennbar ist und die vielen Leuten nicht gefällt.
    • Ich denke, dieser Fork wurde durch diese GitHub-Diskussion ausgelöst.
    • Zed hat VC-Investitionen erhalten. Schon allein deshalb, dass ein Privacy-/Local-first-Fork diese Funktionen nicht ausreichend bietet, hat er eine gewisse eigene Berechtigung. Zwar müsste man viele der Funktionen herausnehmen, mit denen Zed wirbt, aber als echter Rugpull lässt sich das nur schwer bezeichnen.
  • Liste verwandter Diskussions-Threads
  • Ich bin gespannt, was aus diesem Fork wird. Er erinnert mich an IO.js, den damaligen node.js-Fork, der den Entwicklungsverlauf von node verändert hat. In einer Zeit, in der Telemetrie und AI einem überall aufgedrängt werden, fällt dadurch auf, dass es durchaus eine Gruppe von Entwicklern gibt, die auf solche Dinge sensibel reagiert.
  • Was ich mir bei Zed wirklich wünsche, ist Unterstützung für mehrere Fenster. Man kann das Agent-Panel oder andere Panels nicht auf einen anderen Monitor auslagern. Die Local-first-Ausrichtung finde ich zwar gut, aber ich nutze auch AI-Tools, deshalb werde ich diesen Fork vorerst wohl nicht verwenden. Trotzdem begrüße ich die Richtung ohne Telemetrie und ohne Contributor Agreement. Mir gefällt die Idee dieses Forks, und ich wünsche ihm viel Erfolg. Ich habe Zed schon über ein Jahr lang problemlos ohne seine AI-Funktionen genutzt, also könnte ich vielleicht irgendwann, wenn ich AI leid bin, auf diesen Fork umsteigen.
    • Ich hatte dieselbe Erfahrung. Nach all den Diskussionen über Zed habe ich es installiert, aber weil ich keine Panels auslagern konnte und nicht einmal Grundeinstellungen ändern konnte, die seit über einem Jahr nicht behoben wurden, habe ich es direkt wieder gelöscht.
  • Auf so einen Fork habe ich eigentlich schon lange gewartet. Ich habe sogar überlegt, selbst einen zu starten, habe den Plan aber wegen des Wartungsaufwands aufgegeben. Ich hatte auch über den Namen zim nachgedacht, also zed improved, angelehnt an vim. Umso mehr freue ich mich, dass das Projekt nun tatsächlich in der Welt ist.
  • Kommentar des Autors: Lobsters-Original, direkt zum Fork-Projekt. Ich entferne schrittweise Telemetrie, Auto-Updates, Cloud-only-AI-Integrationen, node.js-Abhängigkeiten, automatisches Herunterladen von Sprachservern, Kaufanreize, Login-Buttons und andere Dinge, die ich für mich als unnötig empfinde. Auch die Cloud-only-Funktionen von Zeta edit möchte ich nach Möglichkeit selbst hostbar machen, zum Beispiel indem Zeta-edit-Vorhersagen auf einer llama.cpp- oder vLLM-Instanz ausgeführt werden. Im aktuellen Zustand ist der Editor funktionsfähig genug, um ihn als Haupteditor zu verwenden. Allerdings gibt es wegen der vielen Codeänderungen Grenzen dabei, Merge-Konflikte zu vermeiden. Deshalb experimentiere ich auch damit, mithilfe von tree-sitter Änderungen automatisch auf AST-Ebene vorzunehmen. Dieses Experiment könnte sich zu einem Werkzeug entwickeln, mit dem sich personalisierte „unshittified“-Versionen von Zed erstellen lassen.
    • Ich würde gern nach den node.js-Abhängigkeiten fragen: Seit wann haben die Leute eigentlich angefangen, node nicht zu mögen, und aus welchen Gründen?
  • Ich frage mich, ob für so einen Fork nicht eigentlich schon ein Pull Request ausreichen würde, der die AI-Funktionen in Zed per Compile-Flag ausblendet. Es müsste doch nicht unbedingt ein „Fork“ sein, wenn man mit demselben Code und nur einem anderen Build-Befehl ein Zed ohne AI erzeugen könnte.