Producing Open Source Software
Source: https://producingoss.com/ ↗
Fogel wrote the operational manual for running open-source projects, drawing on his experience as a core Subversion developer and his years observing how projects succeed and fail.
The book covers everything from choosing a license and setting up version control to managing volunteers, handling difficult personalities, and making governance decisions that scale.
Now in its third edition and freely available at producingoss.com, it remains the most practical guide to the organizational side of open source — the side that determines whether good code survives contact with a community.
Fogel treats open-source management as a craft with learnable principles, not as a mystery or a matter of charisma.
For product leaders who interact with open-source communities or who want to open-source their own work, the book provides a framework grounded in decades of accumulated practice.
It is the rare management book that is both honest about human difficulty and genuinely useful.
Central argument
Fogel argues that open-source projects fail not from lack of technical talent but from lack of deliberate organizational design. Drawing on his experience as a core Subversion developer, he contends that governance structures, communication norms, conflict resolution mechanisms, and contribution workflows must be consciously chosen and maintained — that the appearance of organic community growth actually depends on a scaffold of learnable, transferable practices. The central thesis is that open-source management is a craft, not a cultural accident, and that the same decisions that determine whether a license is chosen well also determine whether a volunteer community can survive a difficult personality or a contentious technical dispute.
Critique
The book's primary limitation is that it was shaped almost entirely by the norms of large, infrastructure-oriented open-source projects — version control systems, compilers, server software — where contribution is code-centric and contributors are primarily engineers. This makes its governance frameworks less applicable to open-source projects built around data, design, documentation, or AI models, where the nature of contribution, the definition of quality, and the power dynamics among maintainers look quite different. A thoughtful reader will also notice that the book's treatment of commercial actors — companies that consume or sponsor open-source — has aged unevenly, predating the era when a single corporate contributor can effectively control a nominally open project.
Why it matters for product
For a CPO considering open-sourcing internal tooling or building a product strategy around an open-source core, Fogel's framework makes concrete what is usually left vague: how to structure decision-making authority so that external contributors feel genuine agency without creating governance paralysis, and how to write contribution policies that attract the kind of collaborators who improve the product rather than fragment it. His analysis of how communication channels shape community culture is also directly applicable inside product organizations — the same dynamics that kill an open-source project through mailing-list dysfunction or opaque roadmap decisions are recognizable in how platform teams lose credibility with internal customers.