Open source is one of those subjects where the history is the explanation. Why the licences look the way they do, why maintainers burn out, why two projects with near-identical code have completely different cultures — none of it makes sense from a snapshot of the present. It makes sense as the outcome of an argument that started in the early eighties and has never been resolved.
That argument is the reason order matters here. The free software position and the open source position are not the same thing, their most articulate advocates dislike each other's framing, and a reading list that presents only one reads as propaganda. Read the narrative history first, then both manifestos, then the practical books, then the research.
The prehistory
Hackers is the right first book even though it barely mentions open source. Steven Levy documents the MIT and Homebrew cultures of the sixties and seventies, where sharing code was simply how the work was done, and in doing so he explains what the later movements believed they were defending. Everything afterward is a response to that world ending.
The founding argument, from both sides
The Cathedral and the Bazaar is Eric S. Raymond's 1997 essay arguing that distributed, publicly developed software outcompetes closed development on engineering grounds rather than moral ones. It is the document that produced the term open source and persuaded corporate adopters. Read it with two caveats: its best-known claim, that enough reviewers make every bug shallow, has been badly undercut by long-lived vulnerabilities in heavily used open code, and Raymond's later political writing has drawn substantial criticism that is separate from the essay itself.
Just for fun is Linus Torvalds telling the Linux story in his own voice, which is the most useful corrective to the theory — the actual origin was closer to curiosity and stubbornness than to a development philosophy.
Free as in freedom is Sam Williams on Richard Stallman, the GNU project and the case that software freedom is an ethical question and not an efficiency one. Stallman is a genuinely divisive figure whose conduct has been the subject of public controversy and of his 2019 resignation from the Free Software Foundation and MIT; the ideas and the man are worth assessing separately. Free Software, Free Society collects his own essays, and it is the primary source you should read rather than take second-hand — the copyleft argument is much sharper in his words than in summaries of it.
Actually running a project
Forge Your Future with Open Source is the practical entry point for a first contribution: how to read a project's norms, file a useful issue, and survive a code review from a stranger.
Producing Open Source Software is the book maintainers actually keep. Karl Fogel wrote it from long experience of what makes a project sustainable — communication defaults, decision-making, governance, the mechanics of not being the single point of failure — and it has aged remarkably well. If you read one book here, make it this one.
The Art of Community widens the frame from code to people, and is the better book if your problem is participation rather than process.
Understanding Open Source and Free Software Licensing is the licence-by-licence walkthrough. Honest warning: it dates from 2004, so it predates the AGPL's rise, SPDX identifiers and the recent wave of source-available licences that are not open source at all. Nothing in it is legal advice, and licence questions with money attached need a lawyer.
The research tier
The Success of Open Source is Steven Weber, a political scientist, treating open source as a property-rights and collective-action puzzle rather than a technical one. Coding Freedom is E. Gabriella Coleman's ethnography of Debian, and the sharpest account of how a community's arguments about process are really arguments about values.
Finish with Working in Public, published under the author's earlier name Nadia Eghbal, which describes the shift from communities to lone maintainers serving enormous user bases. It is the most current description of the problem the earlier books did not anticipate.
More software subjects sit under software testing and QA.
Follow the full ordered path here: How to Understand Open Source, in Reading Order.
