The Emacsification of Software

#concept

Summary

Emacs users have always forked plugins, rewritten them for their own config, and never contributed back. thorsten-ball (citing a blog post of this name) argues that behaviour is now becoming the default for all software: when an agent can bend someone else's program to your exact needs in two minutes, the bespoke fork beats the upstream contribution.

Current Understanding

The worked example: he forked a diff viewer called hunk, pointed amp at it, and said "add Gruvbox dark hard theme, add file-checkoff in the sidebar, compile, drop it in ~/bin." Two minutes of agent time. No reason to upstream — the change is bespoke to him, and the cost of maintaining a personal fork has collapsed along with the cost of writing the patch.
The blast radius expands. Not just individuals with small tools: he expects teams and companies to remix mid-sized software. His examples: "I want Riverside but audio-only," or video-only.
Why it matters commercially: general-purpose SaaS has historically been defended by the gap between "close enough" and "exactly what I want." Agents close that gap for free, which is why his prediction list includes it is unclear what software survives — remixability plus per-user custom versions erode the moat.
The OSS side effect: contributions dry up where the incentive to upstream was mostly "so I don't have to maintain a fork." This compounds a claim already in the corpus — that open-source contribution graphs are worth almost nothing now, and giving away near-free code costs little (code-as-throwaway, via sebastian).

Relationship to the sibling concept. explosion-of-internal-software is about building tools that never existed; this page is about remixing tools that do. Same shift — software becoming personal rather than general — from opposite starting points, and both feed the webinar's "little tools you make for yourself" thesis.

Evidence

The Emacsification framing, the hunk fork, the Riverside remix prediction, expanding blast radius — 2026-07-28-agentic-engineering-10x-developer.
OSS growth as low-cost giveaway, contribution graphs devalued — 2026-07-14-sebastian-eugene-interview.
Cost-of-code → zero as the enabling condition — code-as-throwaway.

Concepts: explosion-of-internal-software (sibling mechanism), maintenance-is-the-real-cost (the bounding counterweight), code-as-throwaway (the enabling economics), build-for-the-agent-not-the-human (what happens to the products being remixed), shedding-weight, make-more-cheap-code (a fork nobody else sees is tier-A/B code with a long life)
Entities: thorsten-ball, amp, sebastian

Contradictions / Uncertainty

Maintenance is assumed away. A two-minute fork is cheap; a fork carried across three years of upstream security patches is not. The source does not address rebasing, CVEs in the parent project, or what happens when the agent that built the fork can no longer reconstruct it. (Sourced 2026-07-29: 2026-07-29-what-if-we-vibe-code-it makes exactly this objection — maintenance-is-the-real-cost — and its pendulum case (in-house Jira clone abandoned for Linear within four months) is the mid-size "Riverside but audio-only" prediction failing in the wild. The personal ~/bin fork still passes that source's checklist; the team/company remix he predicts does not.)
Who maintains the upstream if the people capable of patching it now all fork silently? The prediction is stated as an observation, with no answer for the commons problem it describes.
Untested against enterprise-ai-reality: a bespoke unaudited fork in ~/bin is precisely what locked-down corporate environments forbid.

Next Questions

Does a personal fork count as a durable artifact, or is it disposable in the code-as-throwaway sense — regenerated from a prompt against a fresh upstream each time you need it? The second reading is more consistent with the rest of the corpus and would dissolve the maintenance objection.
Is there a non-engineer version of this — remixing a tool you use rather than one you can compile?

4.2 KiB Raw Permalink Blame History