Faça Apps para Linux

Artigo original ↗ Discussão no Hacker News ↗

Apelos para “parar de fazer distribuições Linux e fazer aplicações em vez disso” reacenderam tensões de longa data sobre fragmentação, usabilidade e prioridades no ecossistema Linux. Comentadores argumentam que, embora existam incontáveis distros e window managers, os apps para o usuário final — especialmente os polidos e focados em UX — continuam escassos, dificultados por empacotamento inconsistente, ABIs instáveis e escolhas confusas de toolkit (Qt, GTK, Electron, Flutter, etc.). Muitos veem tecnologias multiplataforma ou web e novos formatos de empacotamento como o Flatpak como caminhos pragmáticos, mas não há consenso sobre como equilibrar conveniência do desenvolvedor, experiência do usuário, abertura e o desejo de obter uma renda sustentável com software para Linux.

Fragmentação das distros vs. aplicações

  • Muitos argumentam que o Linux tem distribuições demais, causando “paralisia da escolha” e diluindo o esforço que poderia ir para aplicações e UX.
  • Outros dizem que a fragmentação é exagerada: a maioria dos usuários de desktop roda Debian/Ubuntu/Mint ou algo parecido; você pode “simplesmente escolher uma” e ficar bem.
  • Alguns veem os apelos por um “One True Linux” como centralização motivada comercialmente; a diversidade é apresentada como criatividade e segurança (evitando monocultura).
  • Contraponto: a diversidade complica a vida de desenvolvedores de apps, que precisam navegar por diferentes distros, DEs e componentes de infraestrutura (Wayland/X11, systemd, etc.).

Empacotamento, ABI e “alvo todas as distros”

  • Desenvolvedores debatem o quão realista é construir uma vez e rodar em todo lugar.
  • Abordagem tradicional: distribuir o código-fonte e usar os gerenciadores de pacotes das distros, ou contar com os mantenedores dos pacotes; desenvolvedores proprietários muitas vezes apenas testam em uma distro e aceitam que os usuários possam fazer ajustes.
  • A distribuição binária é dificultada por problemas de ABI do glibc / libstdc++ e símbolos .so versionados; desenvolvedores de jogos na Steam sentem isso de forma aguda.
  • AppImage, Flatpak, Snap, Steam Runtime e containers são vistos como soluções parciais, mas adicionam complexidade e não escondem totalmente a mudança de ABI.
  • Esquemas de nomes de bibliotecas (-dev, números de versão) confundem iniciantes, mas são explicados como versionamento de ABI e separação entre headers e runtime.

Toolkits e frameworks multiplataforma

  • GNOME/GTK e KDE/Qt são as principais pilhas nativas, mas são criticadas por mudanças de API, UX desigual e alcance multiplataforma limitado.
  • Comparação com macOS/Windows: essas plataformas oferecem frameworks centrais mais ricos e estáveis (gráficos, áudio, ML, etc.), tornando o desenvolvimento de apps mais tranquilo.
  • O Electron é amplamente criticado por ser inchado, mas elogiado por facilitar o suporte ao Linux e viabilizar muitos apps populares.
  • Alternativas mencionadas: Flutter, Kirigami/QtQuick, Java/JavaFX, NW.js, Wails, WebUI; as opiniões divergem sobre desempenho, maturidade e qualidade de UX.
  • Alguns dizem que o desenvolvimento de GUI no Linux é pouco atraente porque é preciso escolher entre várias pilhas imperfeitas.

UX, cultura de CLI e foco no usuário final

  • Um tema recorrente: Linux e FOSS frequentemente investem pouco em UX; muitos usuários aceitam polimento ruim em comparação com macOS/Windows.
  • Debate entre CLI e GUI: alguns afirmam que CLIs são a “pico da UX” para usuários competentes; outros argumentam que CLIs são pesadelos de descoberta e hostis a não especialistas.
  • Vários comentaristas enfatizam que usuários médios precisam de apps intuitivos e visualmente coerentes, não de mais WMs em mosaico ou ferramentas de nicho.

Monetização e economia do código aberto

  • Vários posts descrevem como é difícil viver de apps FOSS (anúncios, doações, recursos premium muitas vezes rendem pouco).
  • Alguns desenvolvedores consideram ou defendem tornar o código fechado (ou source-available, mas com binários pagos) para financiar apps Linux polidos e orientados por UX.
  • Outros enfatizam que uma grande parte dos usuários de Linux prefere fortemente FOSS por motivos de privacidade, longevidade e bloqueio de fornecedor; apps proprietários podem perder esse público.
  • Vários modelos de negócio são discutidos: contratos de suporte, doações/patrocínios, open core, hospedagem paga, binários pagos com código-fonte disponível.

Colaboração vs. “mais um app/distro”

  • Uma corrente incentiva contribuir para apps existentes em vez de reimplementar ferramentas similares ou criar novas distros; esse foco poderia gerar alguns poucos apps excelentes em vez de muitos medíocres.
  • Outra corrente argumenta que o esforço e a motivação de desenvolvedores não são fungíveis: as pessoas mexem no que lhes interessa, não gostam de política de projetos e valorizam a autonomia de “resolver o próprio problema”.
  • A conclusão no fio é mista: mais e melhores apps são desejados, mas tentativas de direcionar centralmente o trabalho de hobbyistas são vistas como irreais e contrárias ao espírito do software livre.