Devtools must be open source

Calls to make developer tools open source so they can be deeply personalized by humans and AI agents collide with practical concerns about maintenance, reliability, and business viability. Commenters argue that while LLMs dramatically lower the barrier to forking and customizing tools, constant AI-driven rebasing, security risks, and UX drift make wholesale source modification a poor substitute for well-designed configuration, plugin systems, and stable APIs. The thread also raises broader worries about how open-source devtools can be sustainably funded in an era where AI can cheaply clone features, and whether relying on closed LLMs as core infrastructure undermines the very openness being advocated.

Scope of “devtools must be open source”

  • Many agree open source is valuable for transparency, trust, and hackability, especially as LLMs lower the barrier to reading and modifying code.
  • Others say most users (even many developers) never touch source; the main benefit historically has been relying on others to inspect and improve it.
  • Some argue trust and UX matter more than license purity; well‑run closed tools can be preferable to poorly maintained open ones.

LLMs, personalization, and forks

  • Several posters actively use LLMs to clone repos, explore code, add niche features, or maintain personal forks; this feels newly feasible.
  • Others warn that maintaining forks (even with agents) is ongoing work: rebasing, resolving conflicts, and tracking UX changes.
  • Proposals like nightly agent‑driven rebases are criticized as brittle, noisy, and potentially “hellish.”

Config, plugins vs source editing

  • Strong pushback against the idea that personalized software obviates config files or plugin systems.
  • Editing constants and recompiling is tolerable for tiny tools; for large systems it’s seen as wasteful, fragile, and hard to keep updated.
  • Plugins, scripting, and well‑designed config are viewed as more sustainable for both public and private customization.

Cost, access, and AI dependence

  • Concern that workflows assuming abundant, frontier‑model tokens ignore real costs and access limits.
  • Some see prices trending down and open models improving; others dislike normalizing LLMs as a required dependency just to configure tools.

Project governance, “AI slop,” and contribution friction

  • Maintainers report being overwhelmed by low‑quality AI‑generated PRs and issues, leading to stricter gatekeeping or ignoring contributions.
  • Contributors are frustrated by radio silence; suggestions include paying maintainers per reviewed/merged PR.
  • Fear that easy AI‑driven copying erodes open‑source competitive advantage and discourages publishing novel techniques.

Business models and ethics

  • Multiple comments note devtools are hard to monetize when users can self‑host or fork, and AI can cheaply recreate commercial offerings.
  • Some see OSS devs turning into “starving artists”; others report making real income selling FLOSS/AGPL software.
  • Debate over whether reselling access to closed LLMs while advocating open devtools is inconsistent or simply pragmatic.