Make Apps for Linux

Original Article ↗ Hacker News Discussion ↗

Calls to “stop making Linux distributions and make applications instead” have reignited long‑running tensions around fragmentation, usability and priorities in the Linux ecosystem. Commenters argue that while there are countless distros and window managers, end‑user apps—especially polished, UX‑focused ones—remain scarce, hindered by inconsistent packaging, unstable ABIs, and confusing toolkit choices (Qt, GTK, Electron, Flutter, etc.). Many see cross‑platform or web technologies and new packaging formats like Flatpak as pragmatic ways forward, but there is no consensus on how to balance developer convenience, user experience, openness, and the desire to earn a sustainable income from Linux software.

Distro Fragmentation vs. Applications

  • Many argue Linux has too many distributions, causing “paralysis of choice” and diluting effort that could go into applications and UX.
  • Others say fragmentation is overstated: most desktop users run Debian/Ubuntu/Mint or similar; you can “just pick one” and be fine.
  • Some see calls for “One True Linux” as commercially motivated centralization; diversity is framed as creativity and security (avoiding monoculture).
  • Counterpoint: diversity complicates life for app developers who must navigate different distros, DEs, and plumbing (Wayland/X11, systemd, etc.).

Packaging, ABI, and “Target All Distros”

  • Developers debate how realistic it is to build once and run everywhere.
  • Traditional approach: ship source and use distro package managers, or rely on the package maintainers; proprietary devs often just test on one distro and accept that users may tweak.
  • Binary distribution is hampered by glibc / libstdc++ ABI issues and versioned .so symbols; game devs on Steam see this acutely.
  • AppImage, Flatpak, Snap, Steam Runtime, and containers are seen as partial solutions, but they add complexity and don’t fully hide ABI churn.
  • Library naming schemes (-dev, version numbers) confuse newcomers but are explained as ABI-versioning and header vs runtime splits.

Toolkits and Cross‑Platform Frameworks

  • GNOME/GTK and KDE/Qt are the main native stacks but are criticized for changing APIs, uneven UX, and limited cross‑platform reach.
  • Comparison to macOS/Windows: those platforms offer richer, more stable core frameworks (graphics, audio, ML, etc.), making app dev smoother.
  • Electron is widely criticized as bloated but praised for making Linux support easy and enabling many popular apps.
  • Alternatives mentioned: Flutter, Kirigami/QtQuick, Java/JavaFX, NW.js, Wails, WebUI; opinions differ on performance, maturity, and UX quality.
  • Some say Linux GUI dev is unattractive because you must choose between several imperfect stacks.

UX, CLI Culture, and End‑User Focus

  • A recurring thread: Linux and FOSS often underinvest in UX; many users accept poor polish compared to macOS/Windows.
  • Debate over CLI vs GUI: some claim CLIs are “peak UX” for competent users; others argue CLIs are discoverability nightmares and hostile to non‑experts.
  • Several commenters stress that average users need intuitive, visually coherent apps, not more tiling WMs or niche tools.

Monetization and Open Source Economics

  • Multiple posts describe how hard it is to make a living from FOSS apps (ads, donations, premium features often underperform).
  • Some devs consider or advocate going closed‑source (or source‑available but paid binaries) to fund polished, UX‑driven Linux apps.
  • Others emphasize that a large subset of Linux users strongly prefer FOSS for privacy, longevity, and lock‑in reasons; proprietary apps may lose that audience.
  • Various business models are discussed: support contracts, donations/sponsorships, open core, paid hosting, paid binaries with source available.

Collaboration vs. “Yet Another App/Distro”

  • One camp urges contributing to existing apps instead of re‑implementing similar tools or spinning new distros; focus could yield a few excellent apps instead of many mediocre ones.
  • Another camp argues that developer effort and motivation are not fungible: people hack on what interests them, dislike project politics, and value the autonomy of “scratching their own itch.”
  • Conclusion in the thread is mixed: more and better apps are desired, but attempts to centrally steer hobbyist labor are seen as unrealistic and contrary to the spirit of libre software.