As soon as I started to use Git I recognized that I would never look at a folder the same way again. I used to work on projects involving several authors, stored in a Dropbox repository, which typically contained dozens of Microsoft Word documents with date prefixes, and often an embarrassingly large number with the word "FINAL" somewhere in the file name. If someone else was working on a document you NEVER opened it. After learning that every change ever made in a software project can be undone, it should be natural to wonder why we don't do everything this way.
But the real power of Git lies not just in the ability to go back in time, but in it's distributed nature. In the Git world-view, there is no "canonical" version of a project. Any project can be cloned, and both copies of the clone are "real". There is tremendous power in this, for it is the power of descent with modification: the driving force of biological evolution. What has worked to select and amplify random mutations in biology must surely work for the purposeful modification of human coders.
Just like in biology, good ideas that occur independently of each other need not exist apart from each other for ever. The process of bringing two different mutations that share a recent common ancestor back together in version control is called a "merge". In biology it's called "sex".
It would be a horrible thing if software developers were the only people who could do it.
Strictly speaking, version control has nothing to do with writing software. It could act on any document with a linear structure (so the diffing algorithm can find the beginning and the end of a change). This includes text documents, spreadsheets, presentations, and DNA sequences.
I propose building Wiki-type software that works like a distributed version control system. In this system any document could be forked, and both versions continue to exist. The author/editor of the cloned document can propose that their changes be merged back to the original, but they also have a new, real-live document with a real URL they can share. The system should be simple enough for non-coders to use: it should be limited to forks, merges and resets, with no need for the command line. There should be a simple rich-text editor for making changes.
I further propose that this system be extended to handle custom fields which are defined by a developer but used by non-developers. For example, a developer could define a "Recipe" data model, and use the system to build a recipe site where any user can fork any other user's recipe, and then propose a merge back to the original (presumably explaining why the change improves it/makes it more delicious).
Distribution powers good ideas because mutations have more places they can happen. Merging brings good ideas together. This is true for biology and software, so it should be for recipes, encyclopaedias, travel guides, scientific papers, lectures, and textbooks.
I have been working on an implementation of this idea which I call "Wikode". There isn't a working production copy of it anywhere yet, but the code is on GitHub and you can download and play with (such as it is).