Nobody's job, everybody's problem: F/OSS in the age of AI

A guest lecture for KAIST CS350 Introduction to Software Engineering.

Most CS students use free/open source software every day. Fewer have seen what happens after a project has users, bug reports, security expectations, and downstreams.

The first half looks at why engineers choose free/open source software, why shared infrastructure often has no clear owner, and how maintainers pay for the work. The second half turns to AI-generated code, using contribution policies from Zig, Ghostty, and Fedify to show how maintainers are responding.

Transcript

1. Nobody’s job, everybody’s problem F/OSS in the age of AI Hong Minhee 洪 民憙 KAIST CS350 · May 13, 2026
2. Hong Minhee Independent free/open source software developer, based in Seoul Creator of Fedify, LogTape, Optique, Hollo, Hackers’ Pub, and others Funded by Sovereign Tech Fund and other public grants, not employed by any company hongminhee.org · dahlia · @hongminhee@hollo.social 洪 民憙 Who’s giving this talk?
3. Part 0 Clearing some fog
4. Two movements, not one Free Software (1983) Richard Stallman, FSF, GNU Project “Free as in speech, not free as in beer” Four freedoms: run it, study it, modify it, distribute your modifications Modifying and redistributing together are what make collaboration possible Ethics-first: software freedom as a user right Open Source (1998) OSI, Eric Raymond The Cathedral and the Bazaar (1997) Transparency, peer review, collaboration Dropped the political framing Engineering-first: open development produces better software
5. A license is what makes it open source No license → all rights reserved by default Publicly visible ≠ publicly usable Open source license: rights to study, modify, and distribute your modifications Free-to-use and source-available licenses fall short of this In practice: a large fraction of public repos have no license at all Publishing source code without a license does not make it open source.
6. Open source can be sold Common models: dual licensing, support contracts, hosted SaaS, open core HashiCorp (Terraform), Redis, Elasticsearch: started open source, built revenue Complications came later (more in part three) Fedify: €192,000 from Sovereign Tech Fund Public grants are a revenue model too Open source describes the license terms, not the price.
7. Part 1 Why open source?
8. DRY, scaled up Why should thousands of companies each write their own HTTP client? Why should every team build and maintain its own logging library? Open source applies DRY at the industry level Shared maintenance, shared improvements, no redundant effort Don’t Repeat Yourself: a principle you know from code.
9. Programming as theory building Programming is not producing text: it is forming a theory Theory in Ryle’s sense: knowing how, not just knowing that The programmer knows why the code is built this way What alternatives were considered and rejected How to safely extend it, how to answer questions about it This knowledge lives in people, not in documents Peter Naur, Programming as Theory Building (1985)
10. “The original powerful structure is still visible, but it has been made completely inoperative by a host of irregular additions.” Peter Naur, on a compiler handed off between teams (1985)
11. Open source distributes the theory Company shuts down → theory holders scatter, theory is gone Open source spreads theory holders beyond any one organization Public development makes theory formation visible: PRs, issues, discussions Fedify: one implementation of ActivityPub’s intricate theory, shared across projects Caveat: not every contributor internalizes the theory. This tension returns in part four. If the theory lives in people, one organization is a single point of failure.
12. Part 2 The paradox of sharing
13. Consolidation creates concentration Pooling work disperses responsibility Dispersed responsibility becomes nobody’s responsibility The fewer maintainers, the more everyone depends on them Consolidation creates a single point of failure at the worst possible moment DRY at scale has a cost.
15. The left-pad incident (2016) Azer Koçulu unpublished all his npm packages in a dispute with npm One of them: left-pad, 11 lines of code that pads a string on the left React, Babel, and thousands of other projects depended on it Builds broke worldwide within minutes npm restored the package by force, overriding its own policies A real single point of failure, failing.
16. A public goods problem Non-excludable: you can’t prevent people from using it Non-rivalrous: one use doesn’t reduce its availability for others Benefits dispersed across many users; costs concentrated on few maintainers Rational actors free-ride: use without contributing Markets systematically under-supply public goods Open source software is a public good.
17. LogTape: designing against fragility Every dependency is a potential left-pad incident Every package is a theory you’re choosing not to understand Keeping the dependency surface small reduces exposure Zero external dependencies: intentional, not accidental A zero-dependency logging library for JavaScript and TypeScript.
18. Part 3 Who pays?
19. The VC model and open source Open source project takes VC investment VC requires returns: monetize, exit, or both Open source is a public good: you can’t exclude free riders Pressure builds to restrict commercial use License changes, acquisitions, or abandonment follow A common pattern with a structural flaw.
20. The license change pattern Project Original license Changed to Year Elasticsearch Apache 2.0 SSPL / ELv2 2021 HashiCorp (Terraform) MPL 2.0 BUSL 1.1 2023 Redis BSD 3-Clause SSPL / RSALv2 2024 The stated reason in each case: large cloud providers running managed versions without contributing back. The community response in all three cases: forks (OpenSearch from Elasticsearch, OpenTofu from Terraform, Valkey from Redis). Three major infrastructure projects, one recurring story.
21. Public funding as a structural response Roads, public education, basic research: the same logic applies Sovereign Tech Fund: digital infrastructure as public infrastructure NLnet Foundation: internet and open standards Linux Foundation, Open Source Initiative, and others Not charity: a deliberate policy response to market failure If markets under-supply public goods, the alternative is public provision.
22. Fedify and the Sovereign Tech Fund ActivityPub is complex, finicky, and repeated work across projects Ghost (major publishing platform) needed it for Social Web features Sovereign Tech Fund granted Fedify €192,000 in 2024 Enables full-time independent development, no employer required Ghost ships the feature; I maintain the infrastructure A concrete example of how public funding works in practice.
23. Part 4 What AI changes
24. Contributor poker Reviewing a PR is betting on the person, not just the code New contributor’s first PR: a bet on their future involvement Each review is part of the contributor’s theory formation Repeat contributions improve; trust grows; co-maintainers emerge The relationship is the point, not any individual patch Loris Cro, Zig community manager
25. AI breaks the bet LLM-generated code submitted without understanding: no theory formation The bet is meaningless if the contributor didn’t engage with the code Maintainer can’t tell whether someone understands what they submitted PR generation cost approaches zero; review cost unchanged The queue fills with PRs the maintainer can’t calibrate What happens when the code wasn’t understood by the person who submitted it?
26. Two separate problems Trust problem Did this contributor understand what they submitted? Disclosure addresses this: more information, better calibration. Review capacity problem AI-generated PRs flood the queue; review is still expensive. Disclosure doesn’t help here. Volume gates or bans do. Not one problem with one solution.
27. Three approaches Zig AI contributions banned PR queue was already unmanageable Addresses: trust and capacity Ghostty Disclose AI use Must fully understand and explain the code Named list for violations Addresses: trust Fedify Disclose AI use PR must link to an accepted issue Human must verify by actually testing “AI is welcome here” Addresses: trust and some capacity
28. Matching the policy to the problem Disclosure addresses trust: more information = better calibration of the bet Disclosure doesn’t reduce review load For most projects: trust is the main issue, so disclosure is enough A ban makes sense when the queue is already unmanageable Zig was at that point; most projects aren’t The two problems call for different responses.
29. What Amp Code does differently A permalink to the AI conversation that produced the change Not just the code: the reasoning, questions asked, decisions made Naur: the theory can’t be fully captured in documents AI conversation threads capture more than commit messages usually do A tool designed to preserve reasoning, not bypass it Amp Code embeds Amp-Thread: URL in commit messages.
30. The problem isn’t AI AI that helps you understand code faster: accelerates theory formation AI that generates PRs you don’t read: undermines it Tool design matters: does it encourage understanding? Policy design matters: does it address trust, capacity, or both? The ecosystem is still working this out The question is whether a given use of AI builds or bypasses theory formation.
31. Further reading Peter Naur, Programming as Theory Building (1985) Loris Cro, Contributor Poker and Zig’s AI Ban (2026) Ghostty, AI Usage Policy Fedify, AI usage policy Amp Code, Thread Sharing
32. Thank you hongminhee.org · dahlia · @hongminhee@hollo.social