Linear-Alternativen: Warum Local-First Issue-Tracking schneller ist als du denkst

Git-Integrationstiefe: Mehr als Commits mit Issues verknüpfen

Die meisten Issue-Tracker behandeln Git-Integration als Feature-Checkbox: Erwähne eine Issue-ID in einer Commit-Nachricht, und ein Link erscheint am Issue. Das ist nützlich, aber oberflächlich.

Beadbox baut auf beads auf, einem Issue-Tracker, bei dem Git-Semantiken die Speicherschicht sind, nicht eine angeschraubte Integration. Dolt, die darunterliegende Datenbank, implementiert Gits Merkle-Tree-Datenmodell für strukturierte Daten. Jede Issue-Änderung ist ein Commit. Jeder Commit hat einen Parent. Du bekommst dolt diff, dolt log und dolt merge auf deiner Issue-History mit denselben Semantiken, die du für Code verwendest.

Was das praktisch bedeutet:

Deine Issue-History ist auditierbar. Die Datenbank selbst ist ein Commit-Graph. Du kannst zwei beliebige Zeitpunkte diffen und genau sehen, welche Felder sich bei welchen Issues geändert haben. Das ist kein aufgeschraubtes "Audit-Log-Feature". Das Speicherformat ist der Audit-Trail.

Branching funktioniert für Issues, nicht nur für Code. Dolt unterstützt Branches nativ. Du kannst deine Issue-Datenbank branchen, um eine Reorganisation auszuprobieren, und sie dann zurückmergen oder verwerfen.

Sync ist Push/Pull, nicht API-Aufrufe. Multi-Maschinen-Zusammenarbeit funktioniert wie git push und git pull. Keine API-Tokens, keine Webhooks, keine OAuth-Flows. Richte dein Dolt-Remote auf einen Server (oder DoltHub) und push. Der andere Rechner pullt.

Hinweis zu Konflikten: Dolt verwendet Three-Way-Merge, genau wie Git. Wenn zwei Personen verschiedene Felder desselben Issues bearbeiten, löst sich der Merge automatisch auf. Wenn zwei Personen dasselbe Feld desselben Issues bearbeiten, entsteht ein Konflikt, der manuell über die Dolt-CLI (dolt conflicts resolve) gelöst werden muss. Beadbox hat noch keine Konfliktlösungs-UI; Konflikte werden auf dolt-Ebene behandelt. In der Praxis sind Konflikte selten, wenn jede Person (oder Agent) an unterschiedlichen Issues arbeitet, was das typische Pattern ist. Aber wenn dein Team häufig dieselben Issues gleichzeitig bearbeitet, ist das ein Reibungspunkt, den du kennen solltest. Die Dolt-Merge-Dokumentation behandelt den Lösungs-Workflow im Detail.

Natives Rendering: Warum wir Node.js in Tauri bündeln

Linear läuft in einem Browser-Tab. Ebenso Jira, Asana und jeder andere SaaS-Tracker. Browser-Tabs konkurrieren um Speicher, werden vom OS suspendiert und rendern über einen Compositor, der Frames an Latenz hinzufügt.

Beadbox läuft als native Desktop-Anwendung, gebaut auf Tauri. Tauri-Apps sind typischerweise winzig (die Tauri-Runtime selbst liegt im einstelligen Megabyte-Bereich), weil sie die native WebView des OS nutzen statt Chromium zu bündeln. Unser Bundle ist mit ~160MB größer als typische Tauri-Apps, und das ist ein bewusster Kompromiss, der erklärt werden sollte.

84MB davon sind eine eingebettete Node.js-Runtime. Wir verwenden eine Sidecar-Architektur: Tauri startet einen Next.js-Server als Kindprozess, der Server-Side Rendering, Server Actions und die WebSocket-Schicht für Echtzeit-Updates übernimmt. Die Tauri-WebView zeigt auf diesen lokalen Server. Wir haben uns dafür statt eines reinen Rust-Backends entschieden, weil das Next.js-Ökosystem uns React Server Components, Server Actions und schnelle Iterationsgeschwindigkeit auf der UI-Schicht gibt. Die Kosten: Bundle-Größe. Eine äquivalente Electron-App wäre 400MB+. Eine reine Rust + Tauri-App wäre unter 10MB, hätte aber 3x länger gedauert und würde das React-Ökosystem verlieren.

Der praktische Unterschied gegenüber einem Browser-Tab: Beadbox rendert in einem dedizierten WebView-Prozess, der keinen Speicher mit deinen anderen 47 Browser-Tabs teilt. Das Aufklappen eines Epic-Baums mit 100+ verschachtelten Issues, das Anwenden von Filtern über ein volles Backlog, das Wechseln zwischen Workspaces: Diese Operationen fühlen sich qualitativ anders an, wenn der Renderer nicht um Ressourcen kämpft.

Erweitern mit der CLI, nicht einer REST-API

Linear hat eine GraphQL-API. Gut gebaut. Aber Linear zu erweitern bedeutet, Code zu schreiben, der mit deren Servern kommuniziert, sich mit deren Tokens authentifiziert und deren Rate Limits handhabt.

Beadbox verfolgt einen anderen Ansatz: Die bd-CLI ist die API. Jede Operation, die die GUI ausführt, geht durch bd, dasselbe Kommandozeilen-Tool, das du in deinem Terminal nutzt.

Hier sind drei Workflows, die du heute copy-pasten kannst:

Massen-Update von Prioritäten für eine Triage-Runde:

# Set all open bugs to priority 1 (critical)
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Tägliche Statuszusammenfassung generieren:

# What changed in the last 24 hours?
echo "=== Closed today ==="
bd list --status=closed --json | \
  jq -r '.[] | select(.updated > (now - 86400 | todate)) | "\(.id) \(.title)"'

echo "=== Currently blocked ==="
bd blocked --json | \
  jq -r '.[] | "\(.id) \(.title) (blocked by: \(.blocked_by | join(", ")))"'

echo "=== Ready to work ==="
bd ready --json | jq -r '.[] | "\(.id) [P\(.priority)] \(.title)"'

KI-Agent erstellt und beansprucht Arbeit:

# Agent discovers a bug, files it, and claims it
ISSUE_ID=$(bd create \
  --title "Fix race condition in auth middleware" \
  --type bug \
  --priority 1 \
  --json | jq -r '.id')

bd update "$ISSUE_ID" --status=in_progress --assignee=agent-3

# ... agent does the work ...

bd update "$ISSUE_ID" --status=closed
bd comments add "$ISSUE_ID" --author agent-3 \
  "Fixed in commit abc1234. Root cause: mutex not held during token refresh."

Wenn du KI-Coding-Agenten einsetzt (Claude Code, Cursor, Copilot Workspace), wissen die bereits, wie man CLI-Befehle ausführt. Keine API-Client-Bibliothek, kein Auth-Tanz. Nur Unix-Pipes und Shell-Skripte.

Probier Beadbox aus, um diese Workflows in Echtzeit visualisiert zu sehen, während Agenten sie ausführen.

Offline-First ist kein Feature, sondern eine Architektur

Manche Cloud-Tracker bieten einen "Offline-Modus", der aktuelle Daten zwischenspeichert und bei Wiederverbindung synchronisiert. Das ist ein Feature, aufgeschraubt auf eine grundsätzlich Online-Architektur. Die Fehlermodi sind vorhersehbar: veralteter Cache, Sync-Konflikte, Operationen, die still in einer Queue landen und später fehlschlagen.

Beadbox funktioniert offline, weil es nie online war. Im Embedded-Modus ist deine gesamte Issue-Datenbank ein Verzeichnis auf deinem Dateisystem. Kein Serverprozess. Kein Daemon. Kein Netzwerk-Socket. Die bd-CLI liest und schreibt in dieses Verzeichnis. Beadbox überwacht es mit fs.watch() und rendert, was es findet.

Es gibt nichts zu synchronisieren, weil es nichts Entferntes gibt. Wenn du dich später für Zusammenarbeit entscheidest, gibt dir Dolts Push/Pull explizite, sichtbare Synchronisation. Aber der Standard ist lokal. Der Standard gehört dir.

Was ist mit Sicherheit? Wenn du Beadbox für Air-gapped oder sensible Umgebungen evaluierst, hier die konkrete Sicherheitslage:

• Verschlüsselung at rest: Beadbox verschlüsselt das .beads/-Verzeichnis selbst nicht. Es verlässt sich auf OS-Level-Festplattenverschlüsselung (FileVault auf macOS, LUKS auf Linux, BitLocker auf Windows). Wenn dein Bedrohungsmodell Verschlüsselung pro Datenbank erfordert, ist das eine Lücke.
• Backups: Dein .beads/-Verzeichnis ist ein normales Verzeichnis. cp -r, rsync, Time Machine oder dolt push zu einem Remote funktionieren alle. Dolts Commit-History bedeutet auch, dass versehentliche Änderungen mit dolt reset zurückgerollt werden können.
• Was den Rechner verlässt: Im Embedded-Modus nichts. Null Netzwerkaufrufe. In der Desktop-App existieren zwei optionale ausgehende Verbindungen: GitHub API zur Prüfung auf Beadbox-Updates (kann in Einstellungen deaktiviert werden), und PostHog-Analytics bei Opt-in (standardmäßig deaktiviert, keine PII gesammelt). Keine davon überträgt Issue-Daten.

Für Air-gapped-Umgebungen, klassifizierte Projekte oder Entwickler, die in Flugzeugen und Zügen arbeiten, ist das kein Nice-to-have. Es ist die einzige Architektur, die funktioniert.

Keine Pro-Sitz-Preisfalle

Linear verlangt $8/month pro Mitglied im Standard-Plan. Vernünftig für ein Fünf-Personen-Team. Weniger vernünftig, wenn dein "Team" 13 KI-Agenten umfasst, die Issues lesen und schreiben müssen.

Das Pro-Sitz-Modell geht von stabilen, menschlich dimensionierten Teams aus. Agentisches Engineering bricht diese Annahme. Du startest vielleicht 3 Agenten für einen Bugfix und 13 für ein Release. Jeder braucht API-Zugang. In SaaS-Preisen ist jeder Agent ein Sitz. Jeder Sitz ist ein Posten auf der Rechnung. Die Kosten skalieren linear mit einer Ressource, die du exponentiell skalierst.

beads ist Open-Source. Die CLI ist kostenlos. Keine Pro-Sitz-Gebühr, kein Nutzungs-Tier, kein "Kontaktieren Sie den Vertrieb für Enterprise." Du kannst 2 Agenten oder 200 gegen dieselbe lokale Datenbank laufen lassen und die Kosten ändern sich nicht.

Beadbox (die GUI) ist während der Beta kostenlos. Die Post-Beta-Preisgestaltung steht noch nicht fest, wird aber nicht pro Sitz sein. Agenten sind keine Menschen. Pro Agent zu berechnen ergibt genauso viel Sinn wie pro Terminalfenster zu berechnen.

Open-Source-Ökosystem

beads ist kein geschlossenes System. Die CLI ist Open-Source unter github.com/steveyegge/beads, und die Community hat 30+ Tools darauf aufgebaut: benutzerdefinierte Reporter, CI-Integrationen, Agent-Orchestrierungsskripte, Dashboard-Erweiterungen und Export-Adapter.

Was das praktisch bedeutet:

Du kannst alles inspizieren. Das Speicherformat ist Dolt, abfragbar mit Standard-SQL. Der CLI-Quellcode ist Go, lesbar und forkbar. Wenn bd create etwas Unerwartetes tut, kannst du den Code lesen, der es ausführt.

Du kannst erweitern, ohne um Erlaubnis zu fragen. Kein Marketplace-Freigabeprozess, kein Partnerprogramm, keine API-Limit-Verhandlung. Schreib ein Shell-Skript, ein Go-Plugin oder einen Python-Wrapper. Das --json-Flag der CLI bei jedem Befehl gibt dir strukturierte Ausgabe zum Weiterleiten an alles, was du baust.

Deine Daten sind portabel. Dolts Push/Pull bedeutet, dass deine Issue-Datenbank auf jedem Server leben kann, den du kontrollierst, mit DoltHub synchronisiert werden oder für immer auf deinem Dateisystem bleiben kann. Es gibt keinen Export-Assistenten, weil es nichts gibt, aus dem exportiert werden müsste. Die Daten gehören bereits dir, in einem Format, das du direkt abfragen kannst.

Die Community baut agentenspezifische Tools. Die Entwickler, die beads täglich nutzen, sind diejenigen, die KI-Agenten-Flotten betreiben. Die Erweiterungen, die sie bauen, lösen Probleme der Agentenkoordination: Batch-Operationen, Skripte zur Abhängigkeitsauflösung, Flottenstatusberichte. Das ist kein theoretisches Community-Engagement. Es sind Praktiker, die Tools für ihre eigenen Workflows bauen und veröffentlichen.

Agenten-orientierte Koordination

Die meisten Issue-Tracker behandeln "Automatisierung" als Webhook, der ausgelöst wird, wenn ein Mensch einen Status ändert. Das ist das Nachrüsten einer API auf einen für Menschen konzipierten Workflow. beads und Beadbox wurden von Anfang an für die Koordination von KI-Agenten entworfen.

Strukturierte Agentenidentität. Jeder Agent hat eine CLAUDE.md-Datei, die seine Rolle, Grenzen und sein Kommunikationsprotokoll definiert. Die --actor- und --author-Flags der bd-CLI verknüpfen jede Aktion mit einem bestimmten Agenten. Wenn eng2 eine Aufgabe übernimmt und einen Plan postet, weiß das System, dass es eng2 war, nicht eine generische "Automatisierung."

Der bd prime-Befehl. Führe bd prime in jedem Workspace aus und es gibt einen Kontextblock aus, der für KI-Coding-Assistenten konzipiert ist. Füge ihn in den System-Prompt deines Agenten ein und er kennt den vollständigen Befehlssatz, Ausgabeformate und Workflow-Patterns. Einem neuen Agenten beads beizubringen dauert einen Befehl, keine Dokumentationsseite.

Abhängigkeitsgraphen, die Agenten tatsächlich nutzen. Agenten arbeiten nicht mit Kanban-Boards. Sie arbeiten mit Bäumen und Blockern. beads verfolgt Eltern/Kind-Beziehungen und blockierende Abhängigkeiten nativ. bd blocked zeigt jedes Bead, das auf etwas wartet. bd ready zeigt alles, was entsperrt und bereit ist. Beadbox rendert dies als interaktiven Abhängigkeitsbaum, in dem du auf einen Blick siehst, was hängt und warum.

Echtzeit-Flottenübersicht. Beadbox überwacht die beads-Datenbank und aktualisiert die UI innerhalb von Sekunden. Das Activity Dashboard zeigt Agenten-Statuskarten (wer aktiv ist, wer still, wer feststeckt), einen Pipeline-Flow (wo sich Arbeit aufstaut) und einen kreuzgefilterten Event-Feed (klick auf einen Agenten, um nur seine Aktionen zu sehen). Das ist die "Missionskontroll"-Ansicht, die 13 parallele Agenten handhabbar macht.

Das richtige Tool für dein Team wählen

Kein Tool ist universell richtig. Hier ein ehrlicher Überblick:

Wähle Linear, wenn:

• Dein Team 10+ Personen umfasst und zentrales Projektmanagement braucht
• Du auf Slack/GitHub/Figma-Integrationen angewiesen bist
• Nicht-technische Stakeholder Zugang zum Issue-Tracker brauchen
• Du verwaltete Infrastruktur ohne operativen Overhead willst
• Du ein Produktteam bist, das in regelmäßigen Zyklen ausliefert

Wähle Beadbox, wenn:

• Dir Datenhoheit wichtig ist (Issues verlassen nie deinen Rechner)
• Du regelmäßig offline oder in eingeschränkten Netzwerkumgebungen arbeitest
• Du KI-Agenten verwaltest, die Issues programmatisch lesen und schreiben müssen
• Du Git-native Issue-History willst (Branch, Diff, Merge deiner Issues)
• Du CLI-First-Workflows mit visuellem Begleiter bevorzugst
• Du ein Solo-Entwickler oder kleines Team (1-10) bist, das keine Enterprise-Features braucht

Behalte dein aktuelles Tool, wenn:

• Die Wechselkosten die Reibung übersteigen, die du erlebst
• Dein Team in Integrationen investiert hat, die von der API des aktuellen Trackers abhängen
• Dein Workflow bereits zu den Meinungen deines Tools passt

Migration von Linear (oder anderen Trackern)

Klartext: Es gibt heute kein automatisiertes Linear-zu-Beadbox-Migrationstool. Keinen CSV-Import-Assistenten, keine API-Brücke, keine Status-Mapping-UI.

Wenn du frisch anfängst, ist das kein Problem. bd init, Issues erstellen, und Beadbox sieht sie sofort. Null Reibung.

Wenn du ein bestehendes Linear-Projekt mitbringen willst, ist der gangbare Weg derzeit geskriptet: Export aus Linears API (CSV und API-Export werden unterstützt), Daten transformieren und bd create in einer Schleife nutzen, um Issues neu zu erstellen. Du verlierst Linear-spezifische Metadaten (Cycles, Projektansichten, SLA-Timer), behältst aber Titel, Beschreibungen, Prioritäten und Status. Ein Migrationsskript ist ein Wochenendprojekt, keine quartalsübergreifende Integration.

Wir wissen, dass das nicht gut genug ist für Teams mit Tausenden Issues und Jahren an History. Eine ordentliche Import-Pipeline steht auf unserer Roadmap, ist aber noch nicht ausgeliefert. Wenn Migrations-Reibung dein primäres Anliegen ist, warte bis wir sie gebaut haben, oder prüfe, ob ein Neustart für deinen Anwendungsfall akzeptabel ist.

Los geht's

Beadbox ist während der Beta kostenlos. Installation mit Homebrew:

brew tap beadbox/cask && brew install --cask beadbox

Wenn du bereits beads nutzt, erkennt Beadbox deine vorhandenen .beads/-Workspaces automatisch. Öffne die App, und deine Issues sind da. Kein Import-Schritt. Keine Kontoerstellung.

Wenn du neu bei beads bist, führt Beadbox dich durch die Initialisierung deines ersten Workspaces. Du schaust in unter 60 Sekunden auf deine Issues.

Lade Beadbox herunter oder schau dir beads an, um zu sehen, ob Local-First Issue-Tracking zu deinem Workflow passt.