Just for Fun: The Story of an Accidental Revolutionary
Source: https://www.harpercollins.com/products/just-for-fun-linus-torvaldsdavid-diamond ↗
The story of Linux told by its creator.
Torvalds started building an operating system as a personal project — no business plan, no ambition to change the world.
What began "just for fun" ended up as critical infrastructure worldwide.
The book captures the dynamics of emergent innovation perfectly: you start for fun, others join because they see value, and the effect compounds.
It is also a practical demonstration of Raymond's thesis: the bazaar works. A direct antidote to the idea that innovation needs a five-year plan.
Central argument
Torvalds argues, partly through the structure of his own life story, that intrinsic motivation — doing something purely for the satisfaction of it — is a more generative engine for innovation than strategic intent. Linux was not designed to disrupt Unix or challenge Microsoft; it was a personal itch scratched in public. The book's implicit thesis is that releasing work openly and inviting collaboration compounds value in ways no single actor could plan, validating what Eric Raymond called the bazaar model: parallel, decentralized contribution outperforms centralized design when the problem space is sufficiently open.
Critique
The Linux origin story is a genuine outlier, and the book does little to interrogate why it worked when most hobbyist open-source projects simply die unnoticed. Torvalds had rare technical credibility, released at a historically precise moment when the internet enabled mass coordination and Unix frustration was peaking — conditions that are not reproducible by will. The risk for a product leader reading this is survivorship bias: treating 'start for fun, let emergence happen' as a repeatable method rather than a post-hoc narrative imposed on an exceptional accident.
Why it matters for product
For a CPO, the most operational insight is about contribution architecture: Linux scaled because Torvalds made the barrier to contribution extremely low and resolved conflicts through technical meritocracy rather than roadmap ownership, which is a direct challenge to how most product organizations gate participation. It also complicates the standard case for OKRs and outcome-based planning — if the highest-leverage work is sometimes work no one would have funded, the question becomes how to create protected space for intrinsic motivation inside a delivery machine without it becoming an excuse for unfocused effort.