Documentation/reproducibility.txt

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