Linear-Alternativen: Warum Local-First Issue-Tracking schneller ist als Sie denken

Linear ist schnell. Anerkennung, wo sie gebuehrt. Sie haben stark in wahrgenommene Performance investiert, und fuer die meisten Teams ist es der beste SaaS-Issue-Tracker auf dem Markt. Aber "bester SaaS" kommt mit Einschraenkungen, die manche Entwickler nicht akzeptieren koennen: Ihre Daten liegen auf den Servern anderer, Ihr Workflow passt sich deren Meinungen an, und jede Interaktion zahlt eine Netzwerk-Roundtrip-Steuer.

Dieser Beitrag ist fuer Entwickler, die an diese Grenzen gestossen sind. Vielleicht verwalten Sie KI-Agent-Flotten, die 50 Issues pro Stunde erstellen. Vielleicht arbeiten Sie air-gapped oder offline-first. Vielleicht wollen Sie einfach keinen Login-Bildschirm zwischen sich und Ihren Issues. Hier ist, was wir beim Bau von Beadbox gelernt haben, einem nativen Desktop-Issue-Tracker, der alles lokal haelt.

Springen Sie direkt zum relevanten Thema:

• Local-First-Geschwindigkeit -- CLI- und UI-Level-Zeitmessungen auf echten Datensaetzen
• Git-native History -- Branchen, Diffen und Mergen Ihrer Issue-Datenbank
• Offline / Air-gapped -- kein Netzwerk, kein Daemon, kein Problem
• Scripting und Agenten -- drei kopierbare Workflows
• Kompromisse -- ehrliche Einschraenkungen, bevor Sie Zeit investieren
• Team-Entscheidungsmatrix -- welches Tool zu welcher Teamstruktur passt
• Migration von Linear -- was existiert und was nicht

Warum Entwickler nach Linear-Alternativen suchen

Die uebliche Antwort ist "Linear ist zu opinioniert." Das stimmt, ist aber ungenau. Linear erzwingt Cycles, Teamstrukturen und Workflow-Status, die davon ausgehen, dass Sie ein Produktteam sind, das in Zwei-Wochen-Kadenzen ausliefert. Wenn das auf Sie zutrifft, ist Linear grossartig. Wenn Sie ein Solo-Entwickler sind, der KI-Agenten koordiniert, oder ein Forschungsteam mit nicht-standardmaessigen Iterationsmustern, oder eine DevOps-Gruppe, die Issues an Git-Commits statt an Slack-Threads binden muss, werden Linears Meinungen zu Reibung.

Das tiefere Problem ist architektonisch. Linear ist ein Cloud-First SaaS-Produkt. Jede Mutation reist zu deren Servern und zurueck. Jede Abfrage haengt von deren Verfuegbarkeit ab. Ihre Issue-Daten existieren in deren Datenbank, abfragbar ueber deren API, zu deren Bedingungen. Fuer die meisten Teams ist das ein akzeptabler Kompromiss. Fuer Entwickler, denen Datenhoheit, Offline-Zugang oder rohe Abfragegeschwindigkeit bei grossen Datensaetzen wichtig ist, ist es ein Dealbreaker.

Was Beadbox nicht kann

Bevor wir darauf eingehen, was Beadbox gut kann, hier die Faelle, in denen es nicht die richtige Wahl ist. Diesen Abschnitt zu ueberspringen hilft nicht; auf diese Grenzen zu stossen, nachdem man ein Tool adoptiert hat, schon gar nicht.

Keine Mehrbenutzter-Berechtigungen oder Zugriffskontrolle. Es gibt keine Benutzerkonten, keine Rollen, keine Sichtbarkeitseinschraenkungen pro Issue. Jeder mit Dateisystemzugriff auf das .beads/-Verzeichnis (oder den Dolt-Server) kann alles lesen und schreiben. Wenn Sie einschraenken muessen, wer was sieht, ist Beadbox heute nichts fuer Sie.

Eingeschraenkte Echtzeit-Zusammenarbeit. Zwei Personen koennen am selben Issue-Set arbeiten, aber das Kollaborationsmodell ist Push/Pull (wie Git), nicht Live-Cursors und Praesenzindikatoren. Im Server-Modus pollt Beadbox alle 3-5 Sekunden auf Aenderungen. Im Embedded-Modus erkennen Dateisystem-Watches Aenderungen schneller (unter einer Sekunde), aber gleichzeitige Schreibvorgaenge auf dieselbe Dolt-Datenbank von zwei Prozessen koennen abstuerzen. Das sichere Muster ist: ein Schreiber gleichzeitig, oder Server-Modus verwenden, wobei Dolt die Nebenlaeufigkeit handhabt.

Keine Integrationen mit Slack, GitHub, Figma oder anderen SaaS-Tools. Der Erweiterungspunkt ist die bd-CLI und Shell-Skripte. Wenn Ihr Workflow von "Issue geschlossen loest Slack-Nachricht aus" abhaengt, muessen Sie diese Verbindung selbst bauen.

Die Skalierungsgrenze ist real, aber entfernt. Wir testen gegen 10K- und 20K-Issue-Datensaetze (siehe Benchmarks unten). Die bewegen sich problemlos. Wir haben nicht bei 100K+ Issues Stresstests gemacht. Wenn Sie eine grosse Organisation sind, die Hunderttausende Issues pro Jahr generiert, ist das unerprobtes Gebiet.

Kein Zugang fuer nicht-technische Stakeholder. Es gibt kein Webportal, keinen Gast-Viewer, keine teilbare Dashboard-URL. Beadbox ist eine Desktop-App, die eine lokale Datenbank liest. Einem PM, der Ihren Rechner nicht nutzt, Fortschritt zu zeigen, bedeutet Screen-Sharing oder ein bd-Skript, das einen Bericht generiert.

Wie Beadbox funktioniert (die 30-Sekunden-Version)

Bevor die Benchmarks Sinn ergeben, hier die Architektur:

Embedded-Modus: Die Dolt-Datenbank lebt in .beads/ auf Ihrem Dateisystem. Kein Serverprozess, kein Daemon. Die bd-CLI liest und schreibt direkt. Beadbox erkennt Aenderungen ueber fs.watch() mit einem 250ms-Debounce und sendet sie per WebSocket an die UI. Das ist der Zero-Setup-Pfad.

Server-Modus: Ein dolt sql-server-Prozess laeuft separat (lokal oder LAN). Die bd-CLI verbindet sich ueber MySQL-Protokoll. Beadbox pollt den Server alle 3-5 Sekunden auf Aenderungen, statt das Dateisystem zu ueberwachen. Dieser Modus unterstuetzt mehrere gleichzeitige Schreiber.

Jede Operation, die die GUI ausfuehrt, laeuft ueber die bd-CLI. Beadbox beruehrt die Datenbank nie direkt. Wenn bd show und Beadbox nicht uebereinstimmen, ist das ein Bug in Beadbox.

Performance: Echte Benchmarks auf einem 10K-Issue-Datensatz

Die beads CLI veroeffentlicht Benchmarks, die Sie auf Ihrer eigenen Hardware reproduzieren koennen. Hier sind echte Zahlen von einem M2 Pro, der die Go-Benchmark-Suite gegen eine 10.000-Issue Dolt-Datenbank ausfuehrt:

Das sind CLI-Level-Benchmarks: die Zeit, die bd braucht, um die lokale Dolt-Datenbank zu lesen oder zu beschreiben. Die Beadbox-UI fuegt Rendering-Overhead hinzu. Unsere Design-Ziele fuer den vollstaendigen Stack (CLI-Aufruf + React-Render + WebSocket-Propagierung) sind:

Wir veroeffentlichen keine Benchmarks gegen Linear oder andere Tracker, weil wir keine kontrollierten Vergleiche durchgefuehrt haben und Rosinenpickerei bei Zahlen nicht ehrlich waere. Was wir sagen koennen: Der gesamte Datenpfad ist lokal. Zwischen dem Klick auf einen Filter und dem Sehen der Ergebnisse liegt kein Netzwerk-Hop. Ob das fuer Sie relevant ist, haengt von Ihrer Baseline ab. Wenn Linear fuer Ihre Datensatzgroesse und Ihren Standort schnell genug fuehlt, ist es das wahrscheinlich. Wenn Sie die Verzoegerung bei einem 500-Issue-Backlog aus einem Konferenzhotel-WLAN gespuert haben, kennen Sie den Schmerz, den diese Zahlen adressieren.

Zum Reproduzieren: Klonen Sie beads, fuehren Sie go test -tags=bench -bench=. -benchmem ./internal/storage/dolt/... aus und vergleichen Sie mit Ihrer Hardware. Zwischengespeicherte Datensaetze landen in /tmp/beads-bench-cache/.

Git-Integrationstiefe: Mehr als Commits mit Issues zu verknuepfen

Die meisten Issue-Tracker behandeln Git-Integration als Feature-Checkbox: Erwaehnen Sie eine Issue-ID in einer Commit-Nachricht, und ein Link erscheint am Issue. Das ist nuetzlich, aber oberflaechlich.

Beadbox baut auf beads auf, einem Issue-Tracker, bei dem Git-Semantiken die Speicherschicht sind, keine aufgeschraubte Integration. Dolt, die darunterliegende Datenbank, implementiert Gits Merkle-Tree-Datenmodell fuer strukturierte Daten. Jede Issue-Aenderung ist ein Commit. Jeder Commit hat einen Parent. Sie bekommen dolt diff, dolt log und dolt merge auf Ihrer Issue-History mit denselben Semantiken, die Sie fuer Code verwenden.

Was das praktisch bedeutet:

Ihre Issue-History ist auditierbar. Die Datenbank selbst ist ein Commit-Graph. Sie koennen zwei beliebige Zeitpunkte diffen und genau sehen, welche Felder sich bei welchen Issues geaendert haben. Das ist kein "Audit-Log-Feature", das obendrauf geschraubt wurde. Das Speicherformat ist der Audit-Trail.

Branching funktioniert fuer Issues, nicht nur fuer Code. Dolt unterstuetzt Branches nativ. Sie koennen Ihre Issue-Datenbank branchen, um eine Reorganisation auszuprobieren, und sie dann zurueckmergen 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. Richten Sie Ihr Dolt-Remote auf einen Server (oder DoltHub) und pushen Sie. Der andere Rechner pullt.

Hinweis zu Konflikten: Dolt verwendet Drei-Wege-Merge, genau wie Git. Wenn zwei Personen verschiedene Felder desselben Issues bearbeiten, loest sich der Merge automatisch auf. Wenn zwei Personen dasselbe Feld desselben Issues bearbeiten, entsteht ein Konflikt, der manuell ueber die Dolt-CLI (dolt conflicts resolve) geloest werden muss. Beadbox hat noch keine Konflikloesungs-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 Muster ist. Aber wenn Ihr Team haeufig dieselben Issues gleichzeitig bearbeitet, ist das ein Reibungspunkt, den Sie kennen sollten. Die Dolt-Merge-Dokumentation behandelt den Loesungs-Workflow im Detail.

Natives Rendering: Warum wir Node.js in Tauri buendeln

Linear laeuft in einem Browser-Tab. Ebenso Jira, Asana und jeder andere SaaS-Tracker. Browser-Tabs konkurrieren um Speicher, werden vom Betriebssystem suspendiert und rendern ueber einen Compositor, der Frames an Latenz hinzufuegt.

Beadbox laeuft 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 Betriebssystems verwenden, statt Chromium zu buendeln. Unser Bundle ist groesser als typische Tauri-Apps mit ~160MB, und das ist ein bewusster Kompromiss, der erklaert werden sollte.

84MB davon sind eine eingebettete Node.js-Runtime. Wir verwenden eine Sidecar-Architektur: Tauri startet einen Next.js-Server als Kindprozess, der serverseitiges Rendering, Server Actions und die WebSocket-Schicht fuer Echtzeit-Updates uebernimmt. Die Tauri-WebView zeigt auf diesen lokalen Server. Wir haben uns dafuer statt eines reinen Rust-Backends entschieden, weil das Next.js-Oekosystem uns React Server Components, Server Actions und schnelle Iterationsgeschwindigkeit auf der UI-Schicht gibt. Die Kosten sind Bundle-Groesse. Eine aequivalente Electron-App waere 400MB+. Eine reine Rust + Tauri-App waere unter 10MB, haette aber 3x laenger gedauert und wuerde das React-Oekosystem verlieren.

Der praktische Unterschied gegenueber einem Browser-Tab: Beadbox rendert in einem dedizierten WebView-Prozess, der keinen Speicher mit Ihren anderen 47 Browser-Tabs teilt. Das Aufklappen eines Epic-Baums mit 100+ verschachtelten Issues, das Anwenden von Filtern ueber ein volles Backlog, das Wechseln zwischen Workspaces: Diese Operationen fuehlen sich qualitativ anders an, wenn der Renderer nicht um Ressourcen konkurriert.

Erweitern mit der CLI, nicht einer REST-API

Linear hat eine GraphQL-API. Sie ist gut konzipiert. 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 ausfuehrt, geht durch bd, dasselbe Kommandozeilen-Tool, das Sie in Ihrem Terminal verwenden wuerden.

Hier sind drei Workflows, die Sie heute kopieren und einfuegen koennen:

Massenaenderung von Prioritaeten fuer 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

Taegliche 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 Sie KI-Coding-Agenten ausfuehren (Claude Code, Cursor, Copilot Workspace), wissen diese bereits, wie man CLI-Befehle ausfuehrt. Keine API-Client-Bibliothek, kein Authentifizierungstanz. Nur Unix-Pipes und Shell-Skripte.

Probieren Sie Beadbox aus, um diese Workflows in Echtzeit visualisiert zu sehen, waehrend Agenten sie ausfuehren.

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, das auf eine grundsaetzlich Online-Architektur aufgeschraubt wurde. Die Fehlermodi sind vorhersehbar: veralteter Cache, Sync-Konflikte, Operationen, die still in einer Queue landen und spaeter fehlschlagen.

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

Es gibt nichts zu synchronisieren, weil es nichts Entferntes gibt. Wenn Sie sich spaeter fuer Zusammenarbeit entscheiden, gibt Ihnen Dolts Push/Pull explizite, sichtbare Synchronisation. Aber der Standard ist lokal. Der Standard gehoert Ihnen.

Was ist mit Sicherheit? Wenn Sie Beadbox fuer Air-gapped oder sensible Umgebungen evaluieren, hier die konkrete Sicherheitslage:

• Verschluesselung at rest: Beadbox verschluesselt das .beads/-Verzeichnis selbst nicht. Es verlaesst sich auf Betriebssystem-Level-Festplattenverschluesselung (FileVault auf macOS, LUKS auf Linux, BitLocker auf Windows). Wenn Ihr Bedrohungsmodell Verschluesselung pro Datenbank erfordert, ist das eine Luecke.
• Backups: Ihr .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 Aenderungen mit dolt reset zurueckgerollt werden koennen.
• Was den Rechner verlaesst: Im Embedded-Modus nichts. Null Netzwerkaufrufe. In der Desktop-App existieren zwei optionale ausgehende Verbindungen: GitHub API zur Pruefung auf Beadbox-Updates (kann in Einstellungen deaktiviert werden), und PostHog-Analytics bei Opt-in (standardmaessig deaktiviert, keine PII gesammelt). Keine davon uebertraegt Issue-Daten.

Fuer Air-gapped-Umgebungen, klassifizierte Projekte oder Entwickler, die in Flugzeugen und Zuegen arbeiten, ist das kein Nice-to-have. Es ist die einzige Architektur, die funktioniert.

Das richtige Tool fuer Ihr Team waehlen

Kein Tool ist universell richtig. Hier ein ehrlicher Ueberblick:

Waehlen Sie Linear, wenn:

• Ihr Team 10+ Personen umfasst und zentrales Projektmanagement braucht
• Sie auf Slack/GitHub/Figma-Integrationen angewiesen sind
• Nicht-technische Stakeholder Zugang zu Ihrem Issue-Tracker brauchen
• Sie verwaltete Infrastruktur ohne operativen Overhead wollen
• Sie ein Produktteam sind, das in regelmaessigen Zyklen ausliefert

Waehlen Sie Beadbox, wenn:

• Ihnen Datenhoheit wichtig ist (Issues verlassen nie Ihren Rechner)
• Sie regelmaessig offline oder in eingeschraenkten Netzwerkumgebungen arbeiten
• Sie KI-Agenten verwalten, die Issues programmatisch lesen und schreiben muessen
• Sie Git-native Issue-History wollen (branchen, diffen, mergen Ihrer Issues)
• Sie CLI-First-Workflows mit visuellem Begleiter bevorzugen
• Sie ein Solo-Entwickler oder kleines Team (1-10) sind, das keine Enterprise-Features braucht

Behalten Sie Ihr aktuelles Tool, wenn:

• Die Wechselkosten die Reibung uebersteigen, die Sie erleben
• Ihr Team in Integrationen investiert hat, die von der API Ihres aktuellen Trackers abhaengen
• Ihr Workflow bereits zu den Meinungen Ihres Tools passt

Migration von Linear (oder anderen Trackern)

Klartext: Es gibt heute kein automatisiertes Linear-zu-Beadbox-Migrationstool. Kein CSV-Import-Assistent, keine API-Bruecke, keine Status-Mapping-UI.

Wenn Sie frisch anfangen, ist das kein Problem. bd init, Issues erstellen, und Beadbox sieht sie sofort. Null Reibung.

Wenn Sie ein bestehendes Linear-Projekt mitbringen wollen, ist der gangbare Weg derzeit geskriptet: Export aus Linears API (CSV und API-Export werden unterstuetzt), Daten transformieren und bd create in einer Schleife verwenden, um Issues neu zu erstellen. Sie verlieren Linear-spezifische Metadaten (Cycles, Projektansichten, SLA-Timer), behalten aber Titel, Beschreibungen, Prioritaeten und Status. Ein Migrationsskript ist ein Wochenendprojekt, keine quartalsuebergreifende Integration.

Wir wissen, dass das nicht gut genug ist fuer Teams mit Tausenden Issues und Jahren an History. Eine ordentliche Import-Pipeline steht auf unserer Roadmap, ist aber noch nicht ausgeliefert. Wenn Migrations-Reibung Ihr primaeres Anliegen ist, warten Sie, bis wir sie gebaut haben, oder bewerten Sie, ob ein Neustart fuer Ihren Anwendungsfall akzeptabel ist.

Erste Schritte

Beadbox ist waehrend der Beta kostenlos. Installation mit Homebrew:

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

Wenn Sie bereits beads verwenden, erkennt Beadbox Ihre vorhandenen .beads/-Workspaces automatisch. Oeffnen Sie die App, und Ihre Issues sind da. Kein Import-Schritt. Keine Kontoerstellung.

Wenn Sie neu bei beads sind, fuehrt Beadbox Sie durch die Initialisierung Ihres ersten Workspaces. Sie werden in unter 60 Sekunden auf Ihre Issues schauen.

Laden Sie Beadbox herunter oder schauen Sie sich beads an, um zu sehen, ob Local-First Issue-Tracking zu Ihrem Workflow passt.