Alternative a Linear: perché l'issue tracking local-first è più veloce di quanto pensi

Profondità dell'integrazione Git: oltre il collegamento dei commit alle issue

La maggior parte degli issue tracker tratta l'integrazione Git come una casella da spuntare: menziona un ID issue in un messaggio di commit e un link appare sulla issue. Utile, ma superficiale.

Beadbox è costruito su beads, un issue tracker dove la semantica Git è il livello di storage, non un'integrazione aggiunta dopo. Dolt, il database sottostante, implementa il modello dati a merkle tree di Git per dati strutturati. Ogni modifica a una issue è un commit. Ogni commit ha un parent. Ottieni dolt diff, dolt log e dolt merge sulla cronologia delle issue con la stessa semantica che usi sul codice.

Cosa significa in pratica:

La cronologia delle tue issue è auditabile. Il database stesso è un grafo di commit. Puoi fare diff tra due punti qualsiasi nel tempo e vedere esattamente quali campi sono cambiati su quali issue. Non è una "funzionalità di audit log" aggiunta sopra. Il formato di storage è l'audit trail.

Il branching funziona sulle issue, non solo sul codice. Dolt supporta i branch nativamente. Puoi creare un branch del tuo database issue per sperimentare con una riorganizzazione, poi fare merge o buttarlo via.

Il sync è push/pull, non chiamate API. La collaborazione multi-macchina funziona come git push e git pull. Nessun token API, nessun webhook, nessun flusso OAuth. Punta il tuo remote Dolt a un server (o DoltHub) e fai push. L'altra macchina fa pull.

Una nota sui conflitti: Dolt usa il three-way merge, come Git. Se due persone modificano campi diversi sulla stessa issue, il merge si risolve automaticamente. Se due persone modificano lo stesso campo sulla stessa issue, ottieni un conflitto che richiede risoluzione manuale tramite la CLI Dolt (dolt conflicts resolve). Beadbox non ha ancora una UI di risoluzione conflitti; gestisci i conflitti a livello dolt. In pratica, i conflitti sono rari quando ogni persona (o agente) lavora su issue distinte, che è il pattern tipico. Ma se il tuo team modifica frequentemente le stesse issue in modo concorrente, è un punto di attrito che dovresti conoscere. La documentazione Dolt sul merge descrive nel dettaglio il workflow di risoluzione.

Rendering nativo: perché includiamo Node.js dentro Tauri

Linear gira in una scheda del browser. Così Jira, Asana e ogni altro tracker SaaS. Le schede del browser competono per la memoria, vengono sospese dal sistema operativo e renderizzano attraverso un compositor che aggiunge frame di latenza.

Beadbox gira come applicazione desktop nativa costruita su Tauri. Le app Tauri sono tipicamente minuscole (il runtime Tauri stesso pesa pochi megabyte) perché usano la WebView nativa del SO invece di includere Chromium. Il nostro bundle è più grande delle app Tauri tipiche, circa 160MB, ed è un compromesso deliberato che vale la pena spiegare.

84MB sono un runtime Node.js integrato. Usiamo un'architettura sidecar: Tauri avvia un server Next.js come processo figlio, che gestisce il rendering lato server, le server action e il livello WebSocket per gli aggiornamenti in tempo reale. La WebView di Tauri punta a questo server locale. Abbiamo scelto questo approccio rispetto a un backend puramente Rust perché l'ecosistema Next.js ci dà React Server Components, server action e velocità di iterazione rapida sul livello UI. Il costo è la dimensione del bundle. Un'app Electron equivalente peserebbe oltre 400MB. Un'app pura Rust + Tauri starebbe sotto i 10MB ma avrebbe richiesto 3 volte il tempo per essere costruita e perderebbe l'ecosistema React.

La differenza pratica rispetto a una scheda del browser: Beadbox renderizza in un processo WebView dedicato che non condivide la memoria con le altre 47 schede del browser. Espandere un albero epic con oltre 100 issue annidate, applicare filtri su un intero backlog, cambiare workspace: queste operazioni si sentono qualitativamente diverse quando il renderer non compete per le risorse.

Estensibilità tramite la CLI, non un'API REST

Linear ha un'API GraphQL. Ben progettata. Ma estendere Linear significa scrivere codice che parla coi loro server, si autentica coi loro token e gestisce i loro rate limit.

Beadbox adotta un approccio diverso: la CLI bd è l'API. Ogni operazione della GUI passa attraverso bd, lo stesso strumento da riga di comando che useresti nel terminale.

Ecco tre workflow che puoi copiare e incollare oggi:

Aggiornamento massivo delle priorità per un giro di triage:

# Imposta tutti i bug aperti a priorità 1 (critica)
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Genera un riepilogo giornaliero dello stato:

# Cosa è cambiato nelle ultime 24 ore?
echo "=== Chiusi oggi ==="
bd list --status=closed --json | \
  jq -r '.[] | select(.updated > (now - 86400 | todate)) | "\(.id) \(.title)"'

echo "=== Attualmente bloccati ==="
bd blocked --json | \
  jq -r '.[] | "\(.id) \(.title) (bloccato da: \(.blocked_by | join(", ")))"'

echo "=== Pronti per il lavoro ==="
bd ready --json | jq -r '.[] | "\(.id) [P\(.priority)] \(.title)"'

Un agente AI crea e prende in carico il lavoro:

# L'agente scopre un bug, lo registra e lo prende in carico
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

# ... l'agente fa il lavoro ...

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."

Se usi agenti AI di coding (Claude Code, Cursor, Copilot Workspace), sanno già come eseguire comandi CLI. Nessuna libreria client API, nessun balletto di autenticazione. Solo pipe Unix e script shell.

Prova Beadbox per vedere questi workflow visualizzati in tempo reale mentre gli agenti li eseguono.

Offline-first non è una funzionalità, è un'architettura

Alcuni tracker cloud offrono una "modalità offline" che mette in cache i dati recenti e sincronizza quando ti riconnetti. Quella è una funzionalità inchiodata sopra un'architettura fondamentalmente online. Le modalità di fallimento sono prevedibili: cache stantia, conflitti di sincronizzazione, operazioni che si accodano in silenzio e falliscono dopo.

Beadbox funziona offline perché non è mai stato online. In modalità embedded, l'intero database delle issue è una directory sul tuo filesystem. Nessun processo server. Nessun daemon. Nessun socket di rete. La CLI bd legge e scrive in quella directory. Beadbox la monitora con fs.watch() e renderizza ciò che trova.

Non c'è nulla da sincronizzare perché non c'è nulla di remoto. Se in seguito scegli di collaborare, il push/pull di Dolt ti dà una sincronizzazione esplicita e visibile. Ma il default è locale. Il default è tuo.

E la sicurezza? Se stai valutando Beadbox per ambienti air-gapped o sensibili, ecco la postura concreta:

• Crittografia a riposo: Beadbox non crittografa la directory .beads/ di per sé. Si affida alla crittografia del disco a livello SO (FileVault su macOS, LUKS su Linux, BitLocker su Windows). Se il tuo modello di minaccia richiede crittografia per singolo database, questo è un gap.
• Backup: La directory .beads/ è una directory normale. cp -r, rsync, Time Machine o dolt push verso un remote funzionano tutti. La cronologia dei commit di Dolt permette anche di annullare modifiche accidentali con dolt reset.
• Cosa esce dalla macchina: In modalità embedded, nulla. Zero chiamate di rete. Nell'app desktop, esistono due connessioni in uscita opzionali: l'API GitHub per controllare aggiornamenti di Beadbox (disattivabile nelle impostazioni) e le analytics PostHog se si opta per l'attivazione (disattivate di default, nessun dato personale raccolto). Nessuna delle due trasmette dati delle issue.

Per ambienti air-gapped, progetti classificati o sviluppatori che lavorano in aereo o in treno, questo non è un nice-to-have. È l'unica architettura che funziona.

Nessuna trappola del prezzo per postazione

Linear addebita $8/month per membro nel piano Standard. Ragionevole per un team di cinque persone. Meno ragionevole quando il tuo "team" include 13 agenti AI che devono leggere e scrivere issue.

Il modello per postazione presuppone team stabili e di dimensioni umane. L'ingegneria agentica rompe questa premessa. Potresti avviare 3 agenti per un bugfix e 13 per un rilascio. Ognuno ha bisogno di accesso API. Nei prezzi SaaS, ogni agente è una postazione. Ogni postazione è una voce in fattura. Il costo scala linearmente con una risorsa che stai scalando esponenzialmente.

beads è open-source. La CLI è gratuita. Nessuna tariffa per postazione, nessun livello di utilizzo, nessun "contatta le vendite per enterprise." Puoi eseguire 2 agenti o 200 sullo stesso database locale e il costo non cambia.

Beadbox (la GUI) è gratis durante la beta. I prezzi post-beta non sono ancora definiti, ma non saranno per postazione. Gli agenti non sono persone. Addebitare per agente ha tanto senso quanto addebitare per finestra di terminale.

Ecosistema open-source

beads non è un giardino recintato. La CLI è open-source su github.com/steveyegge/beads, e la community ha costruito 30+ strumenti sopra: reporter personalizzati, integrazioni CI, script di orchestrazione agenti, estensioni dashboard e adattatori di esportazione.

Cosa significa in pratica:

Puoi ispezionare tutto. Il formato di storage è Dolt, interrogabile con SQL standard. Il codice sorgente della CLI è Go, leggibile e forkabile. Se bd create fa qualcosa di inaspettato, puoi leggere il codice che lo esegue.

Puoi estendere senza chiedere permesso. Nessun processo di approvazione marketplace, nessun programma partner, nessuna negoziazione di limiti API. Scrivi uno script shell, un plugin Go o un wrapper Python. Il flag --json della CLI su ogni comando ti dà output strutturato da incanalare verso qualsiasi cosa costruisci.

I tuoi dati sono portabili. Il push/pull di Dolt permette al tuo database issue di vivere su qualsiasi server che controlli, sincronizzarsi con DoltHub, o restare sul tuo filesystem per sempre. Non c'è wizard di esportazione perché non c'è nulla da cui esportare. I dati sono già tuoi, in un formato che puoi interrogare direttamente.

La community costruisce strumenti specifici per agenti. Gli sviluppatori che usano beads quotidianamente sono quelli che gestiscono flotte di agenti AI. Le estensioni che costruiscono risolvono problemi di coordinazione agenti: operazioni batch, script di risoluzione dipendenze, reporter di stato flotta. Non è impegno comunitario teorico. Sono professionisti che costruiscono strumenti per i propri workflow e li pubblicano.

Coordinazione orientata agli agenti

La maggior parte degli issue tracker tratta "l'automazione" come un webhook che scatta quando un umano cambia uno stato. Questo significa adattare un'API a un workflow pensato per umani. beads e Beadbox sono stati progettati fin dall'inizio per la coordinazione di agenti AI.

Identità strutturata degli agenti. Ogni agente ha un file CLAUDE.md che definisce il suo ruolo, i limiti e il protocollo di comunicazione. I flag --actor e --author della CLI bd collegano ogni azione a un agente specifico. Quando eng2 prende un task e pubblica un piano, il sistema sa che è stato eng2, non una generica "automazione."

Il comando bd prime. Esegui bd prime in qualsiasi workspace e produce un blocco di contesto progettato per assistenti di codifica AI. Incollalo nel prompt di sistema del tuo agente e conoscerà l'intero set di comandi, i formati di output e i pattern di workflow. Insegnare a un nuovo agente a usare beads richiede un comando, non una pagina di documentazione.

Grafi di dipendenza che gli agenti usano davvero. Gli agenti non lavorano con board Kanban. Lavorano con alberi e blocchi. beads traccia nativamente le relazioni padre/figlio e le dipendenze di blocco. bd blocked mostra ogni bead in attesa di qualcos'altro. bd ready mostra tutto ciò che è sbloccato e pronto. Beadbox renderizza questo come un albero di dipendenze interattivo dove puoi vedere a colpo d'occhio cosa è bloccato e perché.

Visibilità della flotta in tempo reale. Beadbox monitora il database beads e aggiorna la UI in pochi secondi. L'Activity Dashboard mostra card di stato degli agenti (chi è attivo, chi silenzioso, chi bloccato), un flusso pipeline (dove si accumula il lavoro) e un feed di eventi con filtro incrociato (clicca su un agente per vedere solo le sue azioni). Questa è la vista "centro di missione" che rende gestibili 13 agenti in parallelo.

Scegliere lo strumento giusto per il tuo team

Nessuno strumento è universalmente corretto. Ecco un'analisi onesta:

Scegli Linear se:

• Il tuo team è di 10+ persone e ha bisogno di project management centralizzato
• Fai affidamento su integrazioni Slack/GitHub/Figma
• Stakeholder non tecnici hanno bisogno di accesso all'issue tracker
• Vuoi infrastruttura gestita con zero overhead operativo
• Sei un team di prodotto che rilascia con cicli regolari

Scegli Beadbox se:

• Tieni alla sovranità dei dati (le issue non lasciano mai la tua macchina)
• Lavori offline regolarmente o in ambienti con rete limitata
• Gestisci agenti AI che devono leggere e scrivere issue programmaticamente
• Vuoi cronologia delle issue Git-native (branch, diff, merge delle tue issue)
• Preferisci workflow CLI-first con un compagno visuale al bisogno
• Sei uno sviluppatore indipendente o un team piccolo (1-10) che non ha bisogno di funzionalità enterprise

Continua a usare il tuo strumento attuale se:

• Il costo del cambio supera l'attrito che stai sperimentando
• Il tuo team ha investito in integrazioni che dipendono dall'API del tracker attuale
• Il tuo workflow si adatta già alle opinioni del tuo strumento

Migrazione da Linear (o altri tracker)

Siamo diretti: oggi non esiste uno strumento di migrazione automatica da Linear a Beadbox. Nessun wizard di importazione CSV, nessun bridge API, nessuna UI di mappatura degli stati.

Se parti da zero, tutto bene. bd init, inizia a creare issue e Beadbox le vede immediatamente. Zero attrito.

Se hai un progetto Linear esistente che vuoi portare, il percorso praticabile al momento è via script: esporta dall'API di Linear (supportano export CSV e API), trasforma i dati e usa bd create in un loop per ricreare le issue. Perderai i metadati specifici di Linear (cicli, viste progetto, timer SLA) ma preserverai titoli, descrizioni, priorità e stato. Uno script di migrazione è un progetto da weekend, non un'integrazione da un trimestre.

Sappiamo che non basta per team con migliaia di issue e anni di cronologia. Costruire una pipeline di importazione adeguata è nella nostra roadmap ma non ancora rilasciata. Se l'attrito della migrazione è la tua preoccupazione principale, aspetta che l'abbiamo costruita, oppure valuta se ripartire da zero è accettabile per il tuo caso d'uso.

Per iniziare

Beadbox è gratis durante la beta. Installalo con Homebrew:

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

Se usi già beads, Beadbox rileva automaticamente i tuoi workspace .beads/ esistenti. Apri l'app e le tue issue sono lì. Nessuna importazione. Nessun account.

Se sei nuovo a beads, Beadbox ti guida nell'inizializzazione del primo workspace. Starai guardando le tue issue in meno di 60 secondi.

Scarica Beadbox o dai un'occhiata a beads per vedere se l'issue tracking local-first si adatta al tuo workflow.