Plurality and a book written in a git repository

The book is the repository, and the readme is about the collaboration

Plurality is a book, and the repository is not a mirror of a finished text. It is where the text is written.

The readme is explicit that while the substance of the book is outlined elsewhere, at www.plurality.net, the purpose of the readme is to provide an overview of the collaboration that will help create the book. The project is described as an open, git-based collaborative book project that aims to offer a vision for the future of technology focused around bridging social difference.

The primary language of the repository is given as Jupyter Notebook, and the top level listing shows why. There is a `contents/` directory, a `design/` directory, `figs/` for figures, `publication/` for the publication pipeline, `docs/`, `scripts/`, `tests/`, and a `noto-emoji/` directory. Alongside them sit `english.md` and `traditional-mandarin.md`, which are the root text entry points for the two languages, and the `package.json` shows the toolchain: VitePress for the website, Vite, Vitest for the tests, pdf-lib and adm-zip for producing the downloadable artifacts, and Vivliostyle for print layout.

So the book exists in three forms at once. There is a website built with VitePress, a downloadable PDF produced from the same sources, and a repository history of every edit made to the text. The primary language being a notebook format is a small signal that the artefacts are generated, not hand assembled.

For a reader, the practical consequence is that this is not a fixed artefact. The text in the repository today is the text, and the version you can fork is whatever the current main branch holds.

Edits are pull requests, and the voice is protected explicitly

The editing model is the standard one, and the readme is refreshingly brief about it, saying it will not be discussed further because it is well documented in many places online. Editing of the root book happens through the standard git issue, fork, pull request, merge process.

What the readme does spend time on is the tension between open participation and a coherent argument, and the answer is stated plainly. In writing this book, the aim is to create a new vision for the future of technology that can help inspire a community to pursue and help create it. The project does not aim primarily at a statement of fact or consensus, though it hopes to help surface facts and promote cooperation across difference. As such, the readme says the maintainers will strive to mostly maintain a coherent argument and authorial voice, rather than combining together separate contributions from distinct authors.

That is a real editorial constraint stated in a repository that is otherwise wide open, and it is worth noticing how it is justified. The argument is that the goal is consistent with a wide range of participation and input, and that the ideas will only succeed if they eventually become a reflection of common sense of a community that pursues them. The readme also says it is seeking to embrace technological advancements in all the work, and therefore welcomes the use of a range of digital assistive tools, such as generative foundation models, in creating contributions.

So the contribution range runs from copyedits to writing the building blocks of text that flesh out an application or restate a principle. The readme asks that the community contribute a range of edits from the small to the large, and lists what those look like: translations, research assistance and editing of the root text, prioritisation of issues and pull requests, maintaining the website interface, graphical design of elements including figures, managing data engines and data visualisation, project management of how those elements interact, and contributing to the tools and platforms that support the collaborative process.

That last item is a detail with real content. The supporting tools are part of the project, not separate.

CC0 content, GPL software, and forks that are meant to diverge

The licensing arrangement is the clearest part of the readme and the most generous.

Everything in the repository and in all other parts of the project, unless explicitly stated otherwise, is in the public domain, and a CC0 licence appears in the repository, while most of the related software has a GPL. The readme strongly encourages translations, both to other languages and to other cultural genres, whether in terms of formatting such as fiction or journalism, or to different communities such as religious, ethnic or disciplinary ones.

And the forks are expected to diverge. While these forks can do whatever they wish with this public domain text, the maintainers plan to link to and recognize only a smaller group of projects that align to the root in terms of content, values, management style and copyrights, and they hope this link and the roots will remain relevant and respected because of the legitimacy the community will achieve through its principles and writing.

That is a two tier structure. Permission is total, recognition is selective, and the reason given for the selection is legitimacy rather than control. A translation into a language the maintainers cannot read is explicitly encouraged, and a translation that is not linked from the root is still perfectly legal.

The repository also ships a `LICENSE` file, and there is a `LICENSES/` directory in the layout, which is the conventional way to record the licence of the code that differs from the licence of the text. The distinction between the CC0 content and the GPL software is the practical one: a translator can take the text into a CC0 derivative without inheriting a copyleft obligation from the publication pipeline.

The citation section provides a BibTeX entry for the book, and the release history shows the tags are dated snapshots of the text rather than versioned packages.

Credit as a governance token, and what it deliberately is not

The identity and credit section describes a mechanism that is worth reading closely, because it is unusual and the readme is careful to bound it.

The project begins as a traditional open source community and eventually hopes to provide more formal governance, participation, control rights and recognition of contributions than has been customary. The stated belief is that such features are important for open source projects to sustainably scale while staying true to their values. The primary goal of the management is therefore to clearly and, for the most part, publicly recognize contributions with both qualitative tokens, which is what kind of contribution was made, and quantitative tokens, which is how important the contribution was.

Then comes the bound. These tokens cannot be traded or transferred directly across users. They are relevant only to governance of and participation in this community and are not intended to have any external financial value, except through the value of the community as a whole. The readme explains that the community may raise some funds to support the community and that the community will govern those funds, but that credit is a marker of contribution and entitlement to governance, not to direct external financial gain.

That is a clean separation of three things people usually conflate: recognition, governance rights and money. The tokens carry the first two and explicitly not the third, and the money is handled by a community-governed fund instead.

There is a second governance mechanism, and it is the more speculative one. The initial maintainers are Audrey Tang, described as Taiwan's first Digital Minister, and E. Glen Weyl, and the plan is to progressively decentralize control of the project using a new git-native formal governance protocol using blockchain-like affordances called Gov4Git, with the transition to full community control planned for when the project prints physical copies of the book.

Recognition itself starts discretionary, with quality and quantity of contributions largely, with some exceptions, beginning as a discretionary choice of the maintainers, and the hope is to transition an increasing range of the mechanisms to formal community governance. There is also a stated plan to introduce privacy features consistent with the ideas in the book, such as designated verifier signatures, with identity roles and credit initially public, possibly pseudonymous, but with no internal privacy controls.

The website, the PDF and the print edition are three different artefacts

The package manifest shows how the book becomes a physical and digital object, and this is where the tooling choices in the repository become meaningful.

The web edition is built with VitePress at version 1.6.4, with Vite and a Vite plugin, and the project uses the Bun package manager with a `bun.lock` at the root. The PDF path is handled by pdf-lib and adm-zip, and the print path by the Vivliostyle CLI, which is a CSS paged media renderer, the kind of tool that turns a browser layout into a paginated document for a book. Vitest is present for the tests, and there is a `tests/` directory and a `scripts/` directory in the layout along with `publication/`.

Three artefacts from one source is a reasonable amount of ambition for a book project, and it explains the primary language. A text file is the source; the website, the PDF and the printed copy are all generated from it. The `design/` directory holds the visual design, `figs/` the figures, and `noto-emoji/` presumably the emoji font assets used in the text.

The `english.md` and `traditional-mandarin.md` files at the root are the two language entry points visible in the layout, which is a useful signal about how translations are meant to work. Rather than a directory per language with its own toolchain, the root text is a single Markdown file per language, and the build takes it from there. That makes a fork cheap: change the entry file, run the build, and the website, the PDF and the print output follow.

The `publication/` directory is the part that a fork has to understand before it can produce anything, because it holds the pipeline that turns the source into the released files. The README does not describe it, and that is a reasonable thing to leave to a contributing guide rather than to the project overview.

Where Plurality is the wrong thing to reach for

There are three reasons a reader should look elsewhere, and they are worth separating because they are different in kind.

The first is that the physical book does not exist yet in the form the governance plan depends on. The plan is to transition to full community control when the project prints physical copies of the book, and the release history shows the most recent tag is a dated snapshot of the text. So the printed edition people have read, if there is one, came from some other build, and a fork starts from whatever the repository holds today rather than from a frozen published text.

The second is that the governance mechanism is a prototype, and the readme says so by describing the intention in the future tense throughout. Gov4Git is described as a new protocol with blockchain-like affordances, the formal community control is something the project eventually hopes to provide, and the privacy features are something the project hopes to introduce in the future. A reader who wants a working decentralised governance system to study is looking for a different artefact, because what is here is a book project that wants to be one.

The third is that the credit system has no use outside the community. Tokens that cannot be traded or transferred, carry no external financial value except through the value of the community as a whole, and are only relevant to governance of and participation in this community, so there is nothing to take away from a fork in a practical sense. A fork gets the text, the licence and the invitation, and not an asset.

What the repository is good for is reading and forking the text. The public domain release means a publisher, a translator or a classroom can take a chapter and reshape it with no legal friction and no need to ask, which is the most useful thing about the project and the part that is actually finished. The governance machinery is the interesting essay inside it, and it is at the stage where the essay is ahead of the implementation.

Editorial conclusion

Plurality fits a reader who wants the argument in a form they can take away and rewrite, in their own language, with the changes tracked, and it fits a governance experimenter who wants a real project to study. It is the wrong tool if you want a finished printed book today, since the plan is to transition to full community control when the physical copies are printed, which has not happened. Before you fork it, verify two things: whether the printed edition you have seen came from this repository or from a different build, since the release tags are dated snapshots and a translation fork will start from whatever text exists today, and how you want to participate in the credit system, because the readme is explicit that recognition is a marker of contribution and entitlement to governance rather than a transferable asset. The content is CC0, the related software is mostly GPL, the repository publishes dated book releases rather than versioned packages, and the last push was on 2026-09-30.

Frequently asked questions

Official sources

1. License: CC0-1.0
2. pluralitybook/plurality on GitHub
3. Project website
4. README
5. Releases