The Sourdough Framework: a book that ships as a reproducible build

A framework for your kitchen, not a recipe for someone else's

The repository's opening line is a rejection of the recipe format. Recipes assume a flour, a starter and an oven much like the author's, and when your kitchen differs, following them closely becomes a way to fail repeatedly. The stated goal here is a framework instead: something that helps you make good bread in your own environment once you understand why the numbers move the way they do.

That framing explains a choice that would otherwise look odd for a book. The project is written in TeX, the repository's primary language, and the emphasis in the README is on scientific references rather than on step-by-step mixes. It also explains the origin. The same author published the-bread-code and pizza-dough repositories four years earlier and describes this project as a merge of that accumulated knowledge, going one step deeper into natural fermentation.

For a reader, the practical consequence is that this is not a book to skim for a weekend bake. It is closer to a course. That does not make it better or worse than a well-tested formula, but it changes what you should expect to get out of the first hour.

One make target produces the PDF

The build has two documented routes and both start the same way. If you have Docker, the top-level makefile is enough, and the output lands at `book/book.pdf`.

make

If Docker is not what you want, the README points at the LaTeX toolchain directly: `biber`, `latexmk` and ImageMagick. In that case you move into `book/` first, because the makefile that knows about the chapters lives there.

cd book/
make

The README is unusually candid about the local path: everything is expected to build without errors, but you should expect a fair amount of warnings, especially when building the ebook and website variants. That is a useful signal about the difference between the two routes. The Docker image is not a convenience wrapper around a fragile build; it pins a large TeX installation and a couple of tools that are painful to install by hand, which is exactly the situation where a warning storm becomes your afternoon.

What the Dockerfile installs and why it is enormous

The `Dockerfile` is worth reading because it explains the project's real dependencies. It starts from `debian:trixie` and installs a full set of publishing tools: `make`, `tidy`, `pandoc`, `zip`, `git`, `wget`, `ruby3.3`, `imagemagick`, `rsync`, `perl` and `xzdec`, plus the TeX packages `texlive-full` and `texlive-luatex`.

Two build steps compile from source rather than using distro packages. `dvisvgm` is fetched as a 3.1.2 release tarball and built with `./configure` and `make`, and `make4ht` is cloned from GitHub and built the same way. On top of that, the image sets `LC_ALL` and `LANG` to `en_US.UTF-8` so the build is UTF-8 throughout, then copies `website/Gemfile`, `website/Gemfile.lock` and `website/.ruby-version` and runs `bundle install`.

So the container is really two toolchains in one image: a LaTeX publishing stack for the book and a Ruby bundle for the website. The image being large is a direct consequence of that, and it is the honest reason this project prefers Docker over asking every reader to reproduce a `texlive-full` plus Ruby setup locally.

Five published formats from one source tree

The `book/` directory is where the sources live, and the same tree produces every published artefact. The README lists the standard PDF and EPUB, an additional sans-serif PDF for accessibility, a black and white EPUB built for file size, and a condensed edition of roughly 15 pages that keeps the flowcharts and leaves room for notes. All of them are built automatically on every push to the `main` branch.

The black and white variant is the one with a stated engineering target: it takes the book from more than 20MB down to about 5MB. That number is the point. A 20MB book is a bad thing to email to someone and an awkward thing to load on a cheap e-reader, so the project treats file weight as a feature target rather than an afterthought.

make bake

produces all of the ebook variants, and the results appear in `book/release/`. The website is built from the same sources, either locally through `make website` from inside `book/`, or through the Docker route by running `make website` at the top level.

cd book/
make website

For local builds the README asks you to install the Ruby version named in `website/.ruby-version` before attempting the website target. That pin is small detail with a real consequence: the website build and the container build can drift apart if you use whatever Ruby happens to be on your system.

A permissive licence on the text, a commercial book on the side

The work is licensed under Creative Commons Attribution-ShareAlike 4.0, which is the right choice for a text that the author wants to spread widely without budget constraints. The README's attribution section is explicit about what that requires in practice: mention the project in your README, in an About section, or in a website or app footer.

At the same time, a hardcover edition is available for purchase, and the author links a donation page alongside it. There is no contradiction here, only a deliberate split. The digital editions are free and open, and the printed object is sold. If you are considering reusing chapters or the flowcharts in a course or a newsletter, the ShareAlike term is the part to read carefully, because derivative works of the text carry the same licence.

Citation is handled properly, which is rarer than it should be. `CITATION.cff` at the repository root is what GitHub's Cite this repository button uses, and the plain text form is given in the README: Kleinwächter, H. (2022). The Sourdough Framework. The Bread Code. Anyone writing an academic reference to the book can copy that rather than reconstructing it.

What the README decides for you, and what it leaves open

The repository is small in a way that is easy to misread. The tree holds `.github/`, `CITATION.cff`, `Dockerfile`, `LICENSE`, `README.md`, `book/`, `makefile` and `website/`. There are no releases published through GitHub, so the downloadable versions come from the author's own hosting rather than from release assets, and there is no changelog to track edits over time. The last push was on 2026-09-17.

What the README settles completely is the build: how to get a PDF, how to get every variant, where the outputs land, and what has to be installed for the local route. That is the part most readers need and most book repositories get wrong.

What it leaves open is everything inside the book. Chapter structure, the actual framework, and the scientific references are all in `book/`, not summarised here. Contributors are welcome to open pull requests for typos and wording, which tells you the book is treated as living text, but the repository is not set up as a collaborative content project the way a software one would be. Read the roughly 15 page condensed edition first and decide from there whether the full book is worth your evening.

Editorial conclusion

The Sourdough Framework is worth reading as a book and worth reading as a repository, for different reasons. The prose argument is that flour, starter and kitchen differ too much for recipes to transfer, so the book hands you a way to reason about your own setup instead of a set of timings. The repository argument is that a single LaTeX source tree produces a PDF, an EPUB, a sans-serif variant, a black and white EPUB under 5MB and a website, all rebuilt on every push to main. What the README settles is the build and the outputs. What it does not settle is the book's internal structure, which lives in the book/ directory, and the citation metadata, which lives in CITATION.cff. Start by reading the roughly 15 page TL;DR edition, because if the framework does not fit how you bake, no amount of remaining chapters will change that.

Frequently asked questions

Official sources

1. hendricius/the-sourdough-framework on GitHub
2. Issues
3. License: CC-BY-SA-4.0
4. Project website
5. README