Talmud: Git version-controlled, free, open, collaboratively-written books the way G-d intended

Having experienced writing an epic tech book - 36 authors and 36 chapters and no, it did not break down nice and neat like that - we are convinced there is a better way than the traditional publishing model. Drawing on the tradition of open source free software about which we wrote, we propose donation-funded, completely free and open texts of superior quality and timeliness, marked by clean mark-up and powered by technologies of collaboration.

(For a good overview of the entire shift in author-reader-publisher relations, read Crag Mod's "Post-Artifact Books and Publishing".)

LaTeX is how a technical text should be typeset. It makes changes trivial, up to the moment ink hits paper, says Hedgemage, who offers to start the LaTeX conversion and teach it to people.

Git helps merging of people's work and especially enables parallel work on different parts of one cohesive whole.

We want to see if we can't raise more funds than we'd get in book royalties anyway to do this process right.

Project name

Name for the overarching project of collaborative, version-controlled writing: Talmud? "The Talmud is a massive work of multiple teachers and explainers working across distance and time to preserve and spread a vast array of knowledge."

Tried to think of the greatest collaboratively written book and all i could come up with is Talmud. The Torah or the New Testament or the Quran (i think?) also are books with many authors (at least the evidence is very strong for the New Testament), but there's the claim that they were written by God more or less directly that makes that less of a choice term- though "The Whatever Bible" is already a series of tech books.

When originally describing this idea as phase two of the Definitive Guide to Drupal 7 in IRC i used the phrase "git version-controlled, open, free books the way G-d intended".

Technical details

Do we really want Git version control? Or do we just want LaTeX on a wiki? We want Git version control. Books should be forkable, worked on individually or in a tight collaboration, and merged back to the main flow.

As diffs are line-based, it would be great to have a way where sentences were considered lines, rather than entire paragraphs, or that everything automatically wrapped and rewrapped at a certain width.

"Machine names" for chapters, which can be replaced with numbers (or not?) when the number and order of chapters is finalized.

The negative example

What we are reacting to in the DGD7 writing cycle.

Problem's due to the benjamin melançon style of doing things:

• too much going on in parallel for ben to coordinate
• many responsibilities left undefined

Problems due to the publisher's non-agile approach or otherwise squarely on the publisher's head:

• changes to chapters turned in at the publisher's request and with plenty of time to go in, and accepted by the publisher with the statement that they would go in, are not in the page proofs. Our contact wrote in response: "I don't have a corrected proof. I have your changes you sent me, and they will be incorporated into the book. If you have anything else you want to add, then you can put it into the page proof on the dropbox, and I will incorporate those additional changes to the ones you already sent."
• "For some strange reason, the compositor named a new of the files different from the rest. But that is the correct one."
  • They split my intromodule chapter into three and i'm ticked about it, but it was done too late to even fight. So i have my own complaints about the process and recommendations and please lay your complaints about my part or any part on me!

Overall: The author write, editor review, author revise, editor review, author proof pipeline proved inflexible and prone to logjams.

Scheduling

A one year write cycle.

Giving a month for every planned ten pages seems reasonable, from experience working with working authors.

So three months to produce a chapter.

Anyone who doesn't deliver after three months gets reassigned to an advisory role, and a new primary author found. (I (ben) would probably have lost all the chapters i ended up doing under this system, and that is fine.)

Editorial decisions

Domain experts would be given special authority over content whether they are authors or not. The point isn't democratic, but open.

As Sarahe says, not doing it "right" but doing it much, much better.