Coming August 2026
Maintainers, founders, and organizations deciding how to run or join an open source project.
Run an open source project people actually want to join.
You can't order volunteers to show up, and free licensing alone won't make them come. This book lays out the concrete habits — open discussion, visible review, low barriers to joining — that make some projects magnets for contributors while others quietly empty out.
You'll know exactly what to fix in how your project runs, not just what license to pick.
Producing Open Source Software — How to Run a Successful Free Software Project · by Karl Fogel · Written by a partner at Open Tech Strategies who has served on the Board of the Open Source Initiative and on the Software Freedom Conservancy's Evaluation Committee.
Why this matters now
You opened the source. You picked a license, maybe even a good one. And still — no pull requests, no mailing list traffic, no community. You start to suspect the code itself is the problem. It probably isn't. Someone visited your project in its first five minutes, found it confusing, and left. You never found out.
Who this is for
- You've open-sourced something and wondered why nobody came.
- You keep walking each new contributor through the same setup steps, one at a time.
- You've watched a technically weaker project pull in more contributors than yours.
- You're deciding whether to open source your company's code and don't know what it will actually cost you.
- You run a project alone and worry what happens to it if you disappear.
What you’ll get from it
- You'll know why lowering the effort it takes a stranger to contribute matters more than adding another feature.
- You'll see why identical code can succeed under one name and fail under another, and how to present your project accordingly.
- You'll learn how to hold real authority over a project without a title or an org chart behind you.
- You'll be able to tell a project that just needs more time from one that's quietly dying.
- You'll understand what a license can and can't do for you, and why culture has to do the rest.
- You'll learn to write onboarding documentation for the reader who knows nothing, not for yourself who already knows everything.
Ideas at the core of the book
Opening your code is real work up front, not a shortcut — the cost comes before any benefit does.
A stranger's first five minutes on your project decide whether they ever come back, and most maintainers never learn when they lose one.
You can't force volunteers to stay. The only thing holding a project together is a shared belief that people do better working together than alone.
Your home page and setup instructions are read as evidence of how much you care, not just as instructions.
Corporations, non-profits, and government agencies fit into open source differently — planning for participation means knowing which you're dealing with.
From the book
“An open license does not guarantee that hordes of active developers will suddenly devote their time to your project, nor does open-sourcing a troubled project automatically cure its ills.”
“The lower a project's hacktivation energy, the better. Your first task is to bring the hacktivation energy down to a level that encourages people to get involved.”
The first chapter, free
Get the opening chapter on what opening your code actually costs before it pays off — the work most maintainers underestimate before they launch.
About the author
Karl Fogel
Karl Fogel is a partner at Open Tech Strategies, LLC, helping for-profit, non-profit, and governmental organizations reach their goals through open source software collaboration and development. He founded QuestionCopyright.org, a U.S. 501(c)3 non-profit organization promoting public understanding of the history and effects of copyright. He served a three-year term on the Board of Directors of the Open Source Initiative and two years as an Open Internet Tools Project Fellow at the New America Foundation. He is a member of Software in the Public Interest and of the Apache Software Foundation, and served five years on the Software Freedom Conservancy's Evaluation Committee.
- · Partner at Open Tech Strategies, LLC
- · Founder of QuestionCopyright.org, a U.S. 501(c)3 non-profit
- · Served a three-year term on the Board of Directors of the Open Source Initiative
- · Two years as an Open Internet Tools Project Fellow at the New America Foundation
- · Five years on the Software Freedom Conservancy's Evaluation Committee
Questions
Is this mainly about the legal side of open source licensing?
No. It covers licensing, including why the GPL's reciprocal terms work the way they do, but the main subject is what happens after you pick a license: how you run the day-to-day culture of the project.
Will open-sourcing our code fix a project that's already struggling?
The book is direct about this: no. An open license doesn't guarantee contributors will show up, and open-sourcing a troubled project doesn't cure what's wrong with it. It walks through what actually draws people in.
Is this for solo maintainers or for companies?
Both. It covers what a solo maintainer decides when launching a project, and what a corporate, non-profit, or government sponsor needs to think about when participating in one.
Do I need to already be running a project to get something out of this?
No. It's also written for the point before you start — deciding whether to open source something and understanding the real cost before you commit.
Producing Open Source Software
You'll know exactly what to fix in how your project runs, not just what license to pick.