From 68abdb734d9c1613527041a489947436b65a3a15 Mon Sep 17 00:00:00 2001 From: Eric Wong Date: Tue, 7 Apr 2020 08:01:36 +0000 Subject: doc: start reproducibility document Not new ideas, just gathering thoughts. --- Documentation/reproducibility.txt | 29 +++++++++++++++++++++++++++++ 1 file changed, 29 insertions(+) create mode 100644 Documentation/reproducibility.txt (limited to 'Documentation') diff --git a/Documentation/reproducibility.txt b/Documentation/reproducibility.txt new file mode 100644 index 00000000..4e56ada4 --- /dev/null +++ b/Documentation/reproducibility.txt @@ -0,0 +1,29 @@ +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 -- cgit v1.2.3-24-ge0c7