|author||Eric Wong <firstname.lastname@example.org>||2020-04-07 08:01:36 +0000|
|committer||Eric Wong <email@example.com>||2020-04-13 21:44:21 +0000|
Not new ideas, just gathering thoughts.
Diffstat (limited to 'Documentation')
1 files changed, 29 insertions, 0 deletions
diff --git a/Documentation/reproducibility.txt b/Documentation/reproducibility.txt
new file mode 100644
@@ -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
+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: firstname.lastname@example.org