Alternative a Linear: perche l'issue tracking local-first e piu veloce di quanto pensi

Linear e veloce. Merito dove e dovuto. Hanno investito parecchio nella performance percepita, e per la maggior parte dei team e il miglior issue tracker SaaS disponibile. Ma "miglior SaaS" porta con se vincoli che alcuni sviluppatori non possono accettare: i tuoi dati vivono sui server di qualcun altro, il tuo workflow si piega per adattarsi alle loro opinioni, e ogni interazione paga un tributo di round-trip di rete.

Questo post e per gli sviluppatori che hanno sbattuto contro quei muri. Forse stai gestendo flotte di agenti AI che creano 50 issue all'ora. Forse lavori in ambienti air-gapped o offline-first. Forse semplicemente non vuoi una schermata di login tra te e le tue issue. Ecco cosa abbiamo imparato costruendo Beadbox, un issue tracker desktop nativo che tiene tutto in locale.

Vai a cio che ti interessa:

• Velocita local-first -- tempi CLI e UI su dataset reali
• Cronologia Git-native -- branch, diff e merge del tuo database issue
• Offline / air-gapped -- nessuna rete, nessun daemon, nessun problema
• Scripting e agenti -- tre workflow da copiare e incollare
• Compromessi -- limitazioni oneste prima di investire tempo
• Matrice decisionale per il team -- quale strumento si adatta a quale tipo di team
• Migrazione da Linear -- cosa esiste e cosa no

Perche gli sviluppatori cercano alternative a Linear

La risposta consueta e "Linear e troppo opinionated". E vero ma impreciso. Linear impone cicli, strutture di team e stati di workflow che presuppongono tu sia un team di prodotto che rilascia ogni due settimane. Se sei quello, Linear e fantastico. Se sei uno sviluppatore solo che coordina agenti AI, o un team di ricerca con pattern di iterazione non standard, o un gruppo DevOps che ha bisogno di issue legate ai commit git piuttosto che ai thread Slack, le opinioni di Linear diventano attrito.

Il problema piu profondo e architetturale. Linear e un prodotto SaaS cloud-first. Ogni mutazione viaggia verso i loro server e ritorno. Ogni query dipende dalla loro disponibilita. I tuoi dati delle issue esistono nel loro database, interrogabili tramite la loro API, alle loro condizioni. Per la maggior parte dei team, e un compromesso accettabile. Per gli sviluppatori che tengono alla sovranita dei dati, all'accesso offline o alla velocita pura delle query su dataset grandi, e un punto di rottura.

Cosa Beadbox non fa

Prima di addentrarci in cio in cui Beadbox eccelle, ecco dove non e la scelta giusta. Saltare questa sezione non ti aiutera; scontrarsi con questi limiti dopo aver adottato lo strumento si.

Nessun permesso multi-utente o controllo degli accessi. Non ci sono account utente, ruoli o restrizioni di visibilita per singola issue. Chiunque abbia accesso al filesystem della directory .beads/ (o al server Dolt) puo leggere e scrivere tutto. Se hai bisogno di limitare chi vede cosa, Beadbox oggi non fa per te.

Collaborazione in tempo reale limitata. Due persone possono lavorare sullo stesso set di issue, ma il modello di collaborazione e push/pull (come Git), non cursori live e indicatori di presenza. In modalita server, Beadbox interroga per le modifiche ogni 3-5 secondi. In modalita embedded, i filesystem watch rilevano le modifiche piu velocemente (sotto il secondo), ma scritture concorrenti allo stesso database Dolt da due processi possono causare crash. Il pattern sicuro e: un solo scrittore alla volta, oppure usa la modalita server con Dolt che gestisce la concorrenza.

Nessuna integrazione con Slack, GitHub, Figma o altri strumenti SaaS. Il punto di estensione e la CLI bd e gli script shell. Se il tuo workflow dipende da "issue chiusa attiva un messaggio Slack", dovrai costruire quel collante da solo.

Il tetto di scalabilita e reale ma lontano. Testiamo con dataset da 10K e 20K issue (vedi benchmark sotto). Reggono bene. Non abbiamo fatto stress test con oltre 100K issue. Se sei un'organizzazione grande che genera centinaia di migliaia di issue all'anno, questo non e territorio testato.

Nessun accesso per stakeholder non tecnici. Non c'e un portale web, un viewer per ospiti o un URL di dashboard condivisibile. Beadbox e un'app desktop che legge un database locale. Mostrare i progressi a un PM che non usa la tua macchina significa una condivisione schermo o uno script bd che genera un report.

Come funziona Beadbox (la versione da 30 secondi)

Prima che i benchmark abbiano senso, ecco l'architettura:

Modalita embedded: Il database Dolt vive in .beads/ sul tuo filesystem. Nessun processo server, nessun daemon. La CLI bd legge e scrive direttamente. Beadbox rileva le modifiche tramite fs.watch() con un debounce di 250ms e le invia via WebSocket alla UI. Questo e il percorso a zero configurazione.

Modalita server: Un processo dolt sql-server gira separatamente (locale o LAN). La CLI bd si connette tramite il protocollo MySQL. Beadbox interroga il server ogni 3-5 secondi per le modifiche invece di monitorare il filesystem. Questa modalita supporta scrittori concorrenti multipli.

Ogni operazione che la GUI esegue passa attraverso la CLI bd. Beadbox non tocca mai il database direttamente. Se bd show e Beadbox non concordano, quello e un bug di Beadbox.

Performance: benchmark reali su un dataset da 10K issue

La CLI di beads pubblica benchmark che puoi riprodurre sul tuo hardware. Ecco numeri reali da un M2 Pro che esegue la suite di benchmark Go contro un database Dolt da 10.000 issue:

Questi sono benchmark a livello CLI: il tempo che impiega bd per leggere o scrivere nel database Dolt locale. La UI di Beadbox aggiunge overhead di rendering. I nostri obiettivi progettuali per lo stack completo (chiamata CLI + render React + propagazione WebSocket) sono:

Non pubblichiamo benchmark rispetto a Linear o altri tracker perche non abbiamo eseguito confronti controllati, e numeri selezionati ad arte non sarebbero onesti. Quello che possiamo dire: l'intero percorso dati e locale. Non c'e nessun hop di rete tra il click su un filtro e la visualizzazione dei risultati. Se questo conti per te dipende dalla tua baseline. Se Linear ti sembra abbastanza veloce per la dimensione del tuo dataset e la tua posizione, probabilmente lo e. Se hai sentito il lag su un backlog da 500 issue dal Wi-Fi di un hotel per conferenze, conosci il dolore che questi numeri affrontano.

Per riprodurre: clona beads, esegui go test -tags=bench -bench=. -benchmem ./internal/storage/dolt/... e confronta con il tuo hardware. I dataset in cache finiscono in /tmp/beads-bench-cache/.

Profondita 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. E utile ma superficiale.

Beadbox e costruito su beads, un issue tracker dove la semantica Git e 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 e un commit. Ogni commit ha un genitore. Ottieni dolt diff, dolt log e dolt merge sulla cronologia delle tue issue con la stessa semantica che usi sul codice.

Cosa significa in pratica:

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

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

Il sync e 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 pusha. 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 e il pattern tipico. Ma se il tuo team modifica frequentemente le stesse issue in modo concorrente, questo e un punto di attrito che dovresti conoscere. La documentazione Dolt sul merge copre il workflow di risoluzione in dettaglio.

Rendering nativo: perche includiamo Node.js dentro Tauri

Linear gira in una scheda del browser. Cosi 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 e di pochi megabyte) perche usano la WebView nativa del sistema operativo invece di includere Chromium. Il nostro bundle e piu grande delle app Tauri tipiche con circa 160MB, ed e un compromesso deliberato che vale la pena spiegare.

84MB di quelli 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 invece di un backend puramente Rust perche l'ecosistema Next.js ci da React Server Components, server action e velocita di iterazione rapida sul livello UI. Il costo e la dimensione del bundle. Un'app Electron equivalente sarebbe oltre 400MB. Un'app pura Rust + Tauri sarebbe 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 tue altre 47 schede del browser. Espandere un albero epic con oltre 100 issue annidate, applicare filtri su un intero backlog, cambiare tra workspace: queste operazioni si sentono qualitativamente diverse quando il renderer non compete per le risorse.

Estensibilita tramite la CLI, non un'API REST

Linear ha una API GraphQL. E ben progettata. Ma estendere Linear significa scrivere codice che parla con i loro server, si autentica con i loro token e gestisce i loro rate limit.

Beadbox adotta un approccio diverso: la CLI bd e l'API. Ogni operazione che la GUI esegue 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 priorita per un giro di triage:

# Imposta tutti i bug aperti a priorita 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 e 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 stai usando agenti AI di coding (Claude Code, Cursor, Copilot Workspace), sanno gia 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 e una funzionalita, e un'architettura

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

Beadbox funziona offline perche non e mai stato online. In modalita embedded, il tuo intero database issue e 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 cio che trova.

Non c'e nulla da sincronizzare perche non c'e nulla di remoto. Se in seguito scegli di collaborare, il push/pull di Dolt ti offre una sincronizzazione esplicita e visibile. Ma il default e locale. Il default e 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 se. Si affida alla crittografia del disco a livello di sistema operativo (FileVault su macOS, LUKS su Linux, BitLocker su Windows). Se il tuo modello di minaccia richiede crittografia per singolo database, questo e un gap.
• Backup: La tua directory .beads/ e una directory normale. cp -r, rsync, Time Machine o dolt push verso un remoto funzionano tutti. La cronologia dei commit di Dolt significa anche che le modifiche accidentali possono essere annullate con dolt reset.
• Cosa esce dalla macchina: In modalita 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 e un nice-to-have. E l'unica architettura che funziona.

Scegliere lo strumento giusto per il tuo team

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

Scegli Linear se:

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

Scegli Beadbox se:

• Tieni alla sovranita 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 accompagnamento visuale quando necessario
• Sei uno sviluppatore solo o un team piccolo (1-10) che non ha bisogno di funzionalita 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 tuo tracker attuale
• Il tuo workflow si adatta gia 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, va benissimo. 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 e via script: esporta dall'API di Linear (supportano esportazione 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, priorita e stato. Uno script di migrazione e un progetto da weekend, non un'integrazione da un trimestre.

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

Per iniziare

Beadbox e gratis durante la beta. Installalo con Homebrew:

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

Se usi gia beads, Beadbox rileva automaticamente i tuoi workspace .beads/ esistenti. Apri l'app e le tue issue sono li. Nessun passaggio di importazione. Nessuna creazione di account.

Se sei nuovo a beads, Beadbox ti guida nell'inizializzazione del tuo primo workspace. Guarderai 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.