Book Review: Working in Public: The Making and Maintenance of Open Source Software

Why this book matters

Modern stacks rest on volunteer labor more than most companies admit. Working in Public by Nadia Eghbal looks at who actually maintains popular open-source projects, why burnout is structural, and how community shape (club, federation, stadium, toy) changes sustainability. If you maintain a library—or your production systems depend on one maintainer’s free nights—this book recalibrates how you think about “open source.”

The diagnosis is sharper than most feel-good FOSS essays. Emotional labor of issues and feature requests, uneven economics, and the gap between users and maintainers are treated as systems problems, not moral failures of individuals.

What it is

Working in Public: The Making and Maintenance of Open Source Software is by Nadia Eghbal (Stripe Press, 2020, 256 pages, ISBN 978-0578675862). It is a research-informed look at open-source ecosystems: maintainer demographics and incentives, community structures, developer burnout, and the economics of infrastructure that often runs without paid staff.

Expect analysis and frameworks more than a how-to for filing your first PR. It is closest to sociology and political economy of software commons, written for practitioners.

The companion Nerd Approved page is the short affiliate micro-review; this log post is the deeper editorial take.

What makes it good

Eghbal’s research reframes habits:

• Who keeps the lights on. The portrait of solo maintainers juggling day jobs explains fragility in critical dependencies. After reading, “star count” looks less like health and more like load.
• Project-type framework. Clubs, federations, stadiums, and toys help explain why some communities thrive under attention while others collapse under their own success. I have used that vocabulary when advising whether to grow a project’s community surface or keep it intentionally small.
• Burnout named honestly. Managing issues, entitlement, and never-ending requests is emotional work. Seeing that named helps maintainers set boundaries—and helps companies understand why throwing pizza money at a crisis is not a sustainability plan.
• Economics without fairy tales. Most maintainers are not getting rich; internet infrastructure still depends on unpaid time. That section should change how engineering orgs budget sponsorship, contribution time, and dependency risk.

The book makes heavy users of open source more responsible consumers—and maintainers less alone in patterns they already feel.

Tradeoffs and who it is not for

Some sections build toward policy or funding discussions that stop short of a concrete playbook. Readers hunting for “ten sustainable funding models with spreadsheets” may finish hungry. It is also not a tutorial on licenses, CI for OSS, or community moderation tooling.

Skip it if you only want a cheerful history of Linux or a beginner guide to contributing. Prefer it for maintainers, platform engineers managing dependency risk, engineering leaders setting contribution/sponsorship policy, and developers who consume open source at scale. Rating-wise I land slightly below a perfect five: the diagnosis is excellent; the prescriptions are thinner.

Verdict

Recommended, with eyes open. Essential reading if you maintain open source or depend on it heavily—the research will change how you see both. Pair it with concrete funding and contribution practices from your org; do not expect the book to finish that work for you.

For ratings, purchase links, and the shorter affiliate-oriented take, see the companion Nerd Approved micro-review. Use this log review for depth; use Nerd Approved when you are ready to buy.