Alternativas ao Linear: Por Que Issue Tracking Local-First e Mais Rapido Do Que Voce Imagina

Linear e rapido. Credito onde e merecido. Eles investiram pesado em performance percebida, e para a maioria dos times, e o melhor issue tracker SaaS disponivel. Mas "melhor SaaS" vem com restricoes que alguns desenvolvedores nao conseguem aceitar: seus dados vivem nos servidores de outra pessoa, seu workflow se adapta as opinioes deles, e toda interacao paga um imposto de ida e volta pela rede.

Este post e para desenvolvedores que bateram nessas paredes. Talvez voce gerencie frotas de agentes de IA que criam 50 issues por hora. Talvez trabalhe air-gapped ou offline-first. Talvez simplesmente nao queira uma tela de login entre voce e seus issues. Veja o que aprendemos construindo o Beadbox, um issue tracker desktop nativo que mantem tudo local.

Va direto ao que importa:

• Velocidade local-first -- Tempos de CLI e UI em datasets reais
• Historico Git-native -- branch, diff e merge no seu banco de issues
• Offline / air-gapped -- sem rede, sem daemon, sem problema
• Scripting e agentes -- tres workflows prontos para copiar e colar
• Tradeoffs -- limitacoes honestas antes de investir seu tempo
• Matriz de decisao por time -- qual ferramenta serve qual formato de time
• Migracao do Linear -- o que existe e o que nao existe

Por que desenvolvedores buscam alternativas ao Linear

A resposta usual e "Linear tem opinioes demais." E verdade, mas impreciso. Linear impoe ciclos, estruturas de time e estados de workflow que assumem que voce e um time de produto entregando em cadencias de duas semanas. Se esse e voce, Linear e otimo. Se voce e um desenvolvedor solo coordenando agentes de IA, ou um time de pesquisa com padroes de iteracao nao padronizados, ou um grupo de DevOps que precisa de issues vinculados a commits git em vez de threads no Slack, as opinioes do Linear se tornam friccao.

O problema mais profundo e arquitetural. Linear e um produto SaaS cloud-first. Cada mutacao viaja para os servidores deles e volta. Cada consulta depende do uptime deles. Seus dados de issues existem no banco de dados deles, consultaveis pela API deles, nos termos deles. Para a maioria dos times, e um tradeoff aceitavel. Para desenvolvedores que se preocupam com soberania de dados, acesso offline, ou velocidade bruta de consulta em datasets grandes, e um deal-breaker.

O que o Beadbox nao faz

Antes de entrar no que o Beadbox faz bem, veja onde ele nao e a escolha certa. Pular esta secao nao vai te ajudar; bater nessas paredes depois de adotar a ferramenta vai.

Sem permissoes multi-usuario ou controle de acesso. Nao ha contas de usuario, papeis, nem restricoes de visibilidade por issue. Qualquer pessoa com acesso ao sistema de arquivos do diretorio .beads/ (ou ao servidor Dolt) pode ler e escrever tudo. Se voce precisa restringir quem ve o que, Beadbox nao e para voce hoje.

Colaboracao em tempo real limitada. Duas pessoas podem trabalhar no mesmo conjunto de issues, mas o modelo de colaboracao e push/pull (como Git), nao cursores ao vivo e indicadores de presenca. No modo servidor, Beadbox faz polling a cada 3-5 segundos. No modo embedded, filesystem watches detectam mudancas mais rapido (sub-segundo), mas escritas concorrentes ao mesmo banco Dolt de dois processos podem crashar. O padrao seguro e: um escritor por vez, ou use modo servidor com Dolt gerenciando a concorrencia.

Sem integracoes com Slack, GitHub, Figma ou outras ferramentas SaaS. O ponto de extensao e o CLI bd e scripts shell. Se seu workflow depende de "issue fechado dispara mensagem no Slack," voce vai precisar construir essa cola.

O teto de escala e real mas distante. Testamos contra datasets de 10K e 20K issues (veja benchmarks abaixo). Esses funcionam bem. Nao fizemos stress test com 100K+ issues. Se voce e uma organizacao grande gerando centenas de milhares de issues por ano, esse nao e territorio comprovado.

Sem acesso para stakeholders nao tecnicos. Nao ha portal web, visualizador para convidados, nem URL de dashboard compartilhavel. Beadbox e um app desktop que le um banco de dados local. Mostrar progresso para um PM que nao usa sua maquina significa compartilhar tela ou um script bd que gera um relatorio.

Como o Beadbox funciona (a versao de 30 segundos)

Antes que os benchmarks facam sentido, aqui esta a arquitetura:

Modo embedded: O banco de dados Dolt vive em .beads/ no seu sistema de arquivos. Sem processo de servidor, sem daemon. O CLI bd le e escreve diretamente. Beadbox detecta mudancas via fs.watch() com debounce de 250ms e transmite por WebSocket para a UI. Esse e o caminho de configuracao zero.

Modo servidor: Um processo dolt sql-server roda separadamente (local ou LAN). O CLI bd conecta via protocolo MySQL. Beadbox faz polling no servidor a cada 3-5 segundos em vez de monitorar o sistema de arquivos. Esse modo suporta multiplos escritores concorrentes.

Toda operacao que a GUI executa passa pelo CLI bd. Beadbox nunca toca no banco de dados diretamente. Se bd show e Beadbox discordam, e um bug no Beadbox.

Performance: benchmarks reais em um dataset de 10K issues

O CLI beads publica benchmarks que voce pode reproduzir no seu proprio hardware. Aqui estao numeros reais de um M2 Pro rodando a suite de benchmarks Go contra um banco Dolt de 10.000 issues:

Esses sao benchmarks de CLI: o tempo que bd leva para ler ou escrever no banco Dolt local. A UI do Beadbox adiciona overhead de renderizacao por cima. Nossos objetivos de design para o stack completo (chamada CLI + render React + propagacao WebSocket) sao:

Nao publicamos benchmarks contra Linear ou outros trackers porque nao rodamos comparacoes controladas, e numeros selecionados a dedo nao seriam honestos. O que podemos dizer: todo o caminho de dados e local. Nao ha salto de rede entre clicar em um filtro e ver os resultados. Se isso importa para voce depende da sua baseline. Se Linear parece rapido o suficiente para o tamanho do seu dataset e sua localizacao, provavelmente e. Se voce ja sentiu o lag em um backlog de 500 issues conectado no Wi-Fi de um hotel de conferencia, voce conhece a dor que esses numeros resolvem.

Para reproduzir: clone beads, rode go test -tags=bench -bench=. -benchmem ./internal/storage/dolt/..., e compare com seu hardware. Datasets em cache ficam em /tmp/beads-bench-cache/.

Profundidade de integracao com Git: alem de vincular commits a issues

A maioria dos issue trackers trata integracao com Git como uma checkbox: mencione um ID de issue numa mensagem de commit, e um link aparece no issue. Isso e util mas superficial.

Beadbox e construido sobre beads, um issue tracker onde semantica Git e a camada de armazenamento, nao uma integracao acoplada depois. Dolt, o banco de dados por baixo, implementa o modelo de dados de arvore merkle do Git para dados estruturados. Cada mudanca de issue e um commit. Cada commit tem um pai. Voce tem dolt diff, dolt log e dolt merge no historico de issues com a mesma semantica que usa no codigo.

O que isso significa na pratica:

Seu historico de issues e auditavel. O banco de dados em si e um grafo de commits. Voce pode fazer diff entre dois pontos no tempo e ver exatamente quais campos mudaram em quais issues. Isso nao e um "recurso de log de auditoria" acoplado depois. O formato de armazenamento e a trilha de auditoria.

Branching funciona em issues, nao so em codigo. Dolt suporta branches nativamente. Voce pode criar uma branch do seu banco de issues para experimentar uma reorganizacao, depois mergear de volta ou descartar.

Sincronizacao e push/pull, nao chamadas de API. Colaboracao multi-maquina funciona como git push e git pull. Sem tokens de API, sem webhooks, sem fluxos OAuth. Aponte seu remote Dolt para um servidor (ou DoltHub) e faca push. A outra maquina faz pull.

Uma nota sobre conflitos: Dolt usa three-way merge, igual ao Git. Se duas pessoas editam campos diferentes no mesmo issue, o merge resolve automaticamente. Se duas pessoas editam o mesmo campo no mesmo issue, voce tem um conflito que requer resolucao manual pelo CLI Dolt (dolt conflicts resolve). Beadbox nao tem UI de resolucao de conflitos ainda; voce resolve conflitos no nivel do dolt. Na pratica, conflitos sao raros quando cada pessoa (ou agente) trabalha em issues distintos, que e o padrao tipico. Mas se seu time edita frequentemente os mesmos issues de forma concorrente, esse e um ponto de friccao que voce deve conhecer. A documentacao de merge do Dolt cobre o workflow de resolucao em detalhe.

Renderizacao nativa: por que incluimos Node.js dentro do Tauri

Linear roda em uma aba do navegador. Jira tambem, Asana tambem, e todo outro tracker SaaS. Abas do navegador competem por memoria, sao suspensas pelo SO e renderizam por um compositor que adiciona frames de latencia.

Beadbox roda como uma aplicacao desktop nativa construida com Tauri. Apps Tauri sao tipicamente minusculos (o runtime do Tauri em si ocupa um digito de megabytes) porque usam o WebView nativo do SO em vez de incluir Chromium. Nosso pacote e maior que apps Tauri tipicos com ~160MB, e esse e um tradeoff deliberado que vale explicar.

84MB disso e um runtime Node.js embutido. Usamos uma arquitetura sidecar: Tauri executa um servidor Next.js como processo filho, que gerencia server-side rendering, server actions e a camada WebSocket para atualizacoes em tempo real. O WebView do Tauri aponta para esse servidor local. Escolhemos isso ao inves de um backend puro Rust porque o ecossistema Next.js nos da React Server Components, server actions e velocidade de iteracao rapida na camada de UI. O custo e tamanho do pacote. Um app Electron equivalente seria 400MB+. Um app puro Rust + Tauri seria menos de 10MB mas teria levado 3x mais tempo para construir e perderiamos o ecossistema React.

A diferenca pratica sobre uma aba do navegador: Beadbox renderiza em um processo WebView dedicado que nao compartilha memoria com suas outras 47 abas. Expandir uma arvore de epic com 100+ issues aninhados, aplicar filtros em um backlog inteiro, trocar entre workspaces: essas operacoes se sentem qualitativamente diferentes quando o renderizador nao esta competindo por recursos.

Estendendo com o CLI, nao com uma API REST

Linear tem uma API GraphQL. E bem projetada. Mas estender o Linear significa escrever codigo que fala com os servidores deles, autentica com os tokens deles e gerencia os rate limits deles.

Beadbox toma uma abordagem diferente: o CLI bd e a API. Toda operacao que a GUI executa passa pelo bd, a mesma ferramenta de linha de comando que voce usaria no terminal.

Aqui estao tres workflows que voce pode copiar e colar hoje:

Atualizar prioridades em massa para uma rodada de triagem:

# Colocar todos os bugs abertos em prioridade 1 (critica)
bd list --status=open --type=bug --json | \
  jq -r '.[].id' | \
  xargs -I{} bd update {} --priority=1

Gerar um resumo de status diario:

# O que mudou nas ultimas 24 horas?
echo "=== Fechados hoje ==="
bd list --status=closed --json | \
  jq -r '.[] | select(.updated > (now - 86400 | todate)) | "\(.id) \(.title)"'

echo "=== Atualmente bloqueados ==="
bd blocked --json | \
  jq -r '.[] | "\(.id) \(.title) (bloqueado por: \(.blocked_by | join(", ")))"'

echo "=== Prontos para trabalhar ==="
bd ready --json | jq -r '.[] | "\(.id) [P\(.priority)] \(.title)"'

Agente de IA cria e reivindica trabalho:

# Agente descobre um bug, registra e reivindica
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

# ... agente faz o trabalho ...

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 voce esta rodando agentes de IA para programar (Claude Code, Cursor, Copilot Workspace), eles ja sabem como rodar comandos CLI. Sem biblioteca de cliente de API, sem danca de autenticacao. Apenas Unix pipes e scripts shell.

Experimente o Beadbox para ver esses workflows visualizados em tempo real conforme os agentes os executam.

Offline-first nao e uma feature, e uma arquitetura

Alguns trackers na nuvem oferecem um "modo offline" que faz cache de dados recentes e sincroniza quando voce reconecta. Isso e uma feature acoplada a uma arquitetura fundamentalmente online. Os modos de falha sao previsiveis: cache obsoleto, conflitos de sincronizacao, operacoes que entram na fila silenciosamente e falham depois.

Beadbox funciona offline porque nunca esteve online. No modo embedded, todo seu banco de issues e um diretorio no seu sistema de arquivos. Sem processo de servidor. Sem daemon. Sem socket de rede. O CLI bd le e escreve nesse diretorio. Beadbox monitora com fs.watch() e renderiza o que encontra.

Nao ha nada para sincronizar porque nao ha nada remoto. Se depois voce quiser colaborar, o push/pull do Dolt te da sincronizacao explicita e visivel. Mas o padrao e local. O padrao e seu.

E quanto a seguranca? Se voce esta avaliando Beadbox para ambientes air-gapped ou sensiveis, aqui esta a postura concreta:

• Criptografia em repouso: Beadbox nao criptografa o diretorio .beads/ por si so. Ele depende de criptografia no nivel do SO (FileVault no macOS, LUKS no Linux, BitLocker no Windows). Se seu modelo de ameacas requer criptografia por banco de dados, essa e uma lacuna.
• Backups: Seu diretorio .beads/ e um diretorio normal. cp -r, rsync, Time Machine, ou dolt push para um remote, tudo funciona. O historico de commits do Dolt tambem significa que mudancas acidentais podem ser revertidas com dolt reset.
• O que sai da maquina: No modo embedded, nada. Zero chamadas de rede. No app desktop, existem duas conexoes de saida opcionais: API do GitHub para verificar atualizacoes do Beadbox (pode ser desabilitada em configuracoes), e analytics PostHog se voce optar por habilitar (desabilitado por padrao, nenhum PII coletado). Nenhuma transmite dados de issues.

Para ambientes air-gapped, projetos classificados, ou desenvolvedores que trabalham em avioes e trens, isso nao e um nice-to-have. E a unica arquitetura que funciona.

Escolhendo a ferramenta certa para seu time

Nenhuma ferramenta e universalmente correta. Aqui esta um detalhamento honesto:

Escolha Linear se:

• Seu time tem 10+ pessoas e precisa de gerenciamento de projetos centralizado
• Voce depende de integracoes com Slack/GitHub/Figma
• Stakeholders nao tecnicos precisam de acesso ao seu issue tracker
• Voce quer infraestrutura gerenciada com zero overhead operacional
• Voce e um time de produto entregando em ciclos regulares

Escolha Beadbox se:

• Voce valoriza soberania de dados (issues nunca saem da sua maquina)
• Voce trabalha offline regularmente ou em ambientes de rede restritos
• Voce gerencia agentes de IA que precisam ler e escrever issues programaticamente
• Voce quer historico de issues Git-native (branch, diff, merge seus issues)
• Voce prefere workflows CLI-first com um companheiro visual quando necessario
• Voce e desenvolvedor solo ou time pequeno (1-10) que nao precisa de features enterprise

Continue com sua ferramenta atual se:

• O custo de troca excede a friccao que voce esta enfrentando
• Seu time investiu em integracoes que dependem da API do seu tracker atual
• Seu workflow ja se encaixa nas opinioes da sua ferramenta

Migrando do Linear (ou outros trackers)

Vamos ser diretos: nao existe ferramenta automatizada de migracao do Linear para o Beadbox hoje. Sem wizard de importacao CSV, sem ponte de API, sem UI de mapeamento de status.

Se voce esta comecando do zero, perfeito. bd init, comece a criar issues, e o Beadbox os ve imediatamente. Zero friccao.

Se voce tem um projeto Linear existente que quer trazer, o caminho viavel agora e via script: exporte da API do Linear (eles suportam exportacao CSV e API), transforme os dados, e use bd create em loop para recriar os issues. Voce vai perder metadados especificos do Linear (ciclos, views de projeto, timers de SLA) mas preserva titulos, descricoes, prioridades e status. Um script de migracao e um projeto de fim de semana, nao uma integracao de um trimestre.

Sabemos que isso nao e bom o suficiente para times com milhares de issues e anos de historico. Construir um pipeline de importacao adequado esta no nosso roadmap mas ainda nao foi entregue. Se friccao de migracao e sua preocupacao principal, espere ate termos construido, ou avalie se comecar do zero e aceitavel para seu caso de uso.

Comecando

Beadbox e gratuito durante o beta. Instale com Homebrew:

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

Se voce ja usa beads, o Beadbox detecta seus workspaces .beads/ existentes automaticamente. Abra o app e seus issues estao la. Sem etapa de importacao. Sem criacao de conta.

Se voce e novo no beads, o Beadbox te guia para inicializar seu primeiro workspace. Voce estara olhando seus issues em menos de 60 segundos.

Baixe o Beadbox ou confira o beads para ver se issue tracking local-first se encaixa no seu workflow.