+reproducibility => forkability
+------------------------------
+
+The ability to fork a project is a checks and balances
+system for free software projects. Reproducibility is key
+to forkability since every mirror is potential fork.
+
+git makes the code history of projects fully reproducible.
+public-inbox uses git to make the email history of projects
+reproducible.
+
+Keeping all communications as email ensures the full history
+of the entire project can be mirrored by anyone with the
+resources to do so. Compact, low-complexity data requires
+less resources to mirror, so sticking with plain-text
+ensures more parties can mirror and potentially fork the
+project with all its data.
+
+Any private or irreproducible data is a barrier to forking.
+These include mailing list subscriber information and
+non-federated user identities. The "pull" subscriber model
+of NNTP and Atom feeds combined with open-to-all posting
+means there's no need for private data.
+
+If these things make power hungry project leaders and admins
+uncomfortable, good. That was the point. It's how checks
+and balances ought to work.
+
+Comments, corrections, etc welcome: meta@public-inbox.org