Open source can't coordinate?

Original Article ↗ Hacker News Discussion ↗

Linux Desktop Fragmentation & Coordination

  • Many argue Linux as a consumer OS lacks a coordinating “reference platform” like Windows/macOS. Vendors (distros, DEs, toolkits, packagers) share power but no one optimizes end‑to‑end user experience.
  • Attempts at coordination (freedesktop.org, Wayland, LSB) helped for DEs and graphics, but application portability and packaging remain messy.
  • Some think this is not uniquely an OSS problem: proprietary ecosystems also fragment (multiple Windows GUI stacks, WinUI vs UWP vs Win32, Electron, etc.).

Choice vs Cohesion (systemd, drivers, desktops)

  • systemd is a central example: supporters say it filled a crucial gap and enabled a more coherent platform; critics say it killed alternatives and reduced choice.
  • Underlying tension: “many options” vs “one robust, standard way.” Some argue too much choice hurts users (audio stacks, multiple DEs, init systems).
  • Hardware and driver issues are framed as a clash between FOSS ideals and proprietary blobs; this harms desktop adoption, especially on laptops.

Android, ChromeOS, and Alternative Baselines

  • Some propose that distros should have rallied around Android/AOSP as a common app platform, reusing Google’s investment and ecosystem.
  • Others respond that Android is technically and philosophically ill‑suited for desktops (sandboxing model, restricted userland, UI assumptions, dependence on Google, OEM bloat/spying).

Packaging, Compatibility & App Distribution

  • Binary compatibility across distros is considered painful (DEB vs RPM vs others).
  • Flatpak/Snap/AppImage are seen as partial solutions: they improve “compile once, run anywhere” but introduce tradeoffs in storage, RAM, and complexity; layering/dedup can mitigate some bloat.

Standards & Protocols: LSP, POSIX, XDG

  • Some agree with the article that OSS “missed” a chance to create an IDE protocol before LSP; others say the ecosystem and tooling (e.g. GitHub, language maturity) weren’t ready.
  • LSP gets mixed reviews: praised for enabling IDE‑like features in editors (vim/emacs), but criticized as underspecified, buggy across servers, and de‑facto biased toward VS Code.
  • POSIX is cited as “coordination after the fact”: it standardizes common denominators once multiple implementations already exist, often with long delays (e.g., strlcpy/strlcat).
  • Slow adoption of obvious improvements like XDG base dirs is another example of coordination friction.

Governance, Incentives & “Jerk” Maintainers

  • Several comments argue the core issue is incentives: corporations pay people to coordinate; FOSS relies on volunteers whose priority is their own project, not global coherence.
  • Strong maintainers (sometimes abrasive) can both protect quality and block useful changes for years; forking is the ultimate escape hatch but costly for most users.
  • Others see the lack of a single authority as a feature: open source optimizes for freedom and experimentation rather than a uniform, polished cathedral.