A book is no longer be a book, but parallel variations on a theme. A spectrum of perspectives, built like software is done these days.

This made me think of how Aztecs used to keep track of histories.

Dr Marysol Ortega^∇

Why rMake?

Writing a book is mostly a one-person writing exercise and that’s a problem. Using today’s tools, if the book has more than one author, they may have discussions, critiques, suggestions, etc., but, after all is said and done, the actual writing is done by one of them.

Another problem is assigning authorship and ownership. A handful of people get listed as co-authors and they also get equal co-ownership of the work. Others who have contributed significantly to the book may end up as “advisors” or “my good friend” but not considered a co-author. Still others may get mentioned in the acknowledgements section or in footnotes. In academic circles, the latest is to list everybody in a lab, sometimes hundreds of them. Unfortunately, none of this really comes close to creating a book as a team, similarly to the way we make software.

The intent of rMake is to make it possible for many people to contribute to a book and get consistent authorship and ownership. What would have been a laborious process for books written with a quill pen or a typewriter, it is a piece of cake using basic modern technology.

But You Already Can, Can’t You?

My first thought was that any of the various Git^∇ platforms, MediaWiki,^∇ or even Google Docs could be it.

	Git
PROs	Git is a very popular software source control^∇ system. It allows software developers to work as peers, in parallel. The published code lives in the project trunk. Any developer can read that code at any time. Several developers can work on features or new versions of the code in parallel, in separate branches. Each is persistent and fully rendered. Whenever I want to merge the code in my flow into the trunk, I create a pull request for the trunk’s admin. We’d have a discussion about my branch in the pull request and if everything lines up, the code in my branch is merged into the trunk. If anybody wants to, they can fork the code and create their own version of the software.
CONs	Git and its many derivatives are not what you’d call user friendly for non-developers. The trunk is the boss and it is the only one that counts (i.e., gets compiled into production). Branches are ephemeral, second class objects.

	MediaWiki
PROs	This is the wiki engine used by Wikipedia and it is friendly enough for writers. At least those who are used to Wiki Markup.^∇ It keeps a history of the document where you can see all the edits ever made to a page as well as the discussions between the page editor and other contributors. Various writers can work asynchronously (not quite in parallel). It is Open Source. It has pretty good documentation for developers.^∇
CONs	It only renders the latest version of the document. All changes are kept in the History tab, but the only version rendered in the latest one, with all the accepted changes. There’s no way to see previous versions, except by reading the History and applying heavy use of your imagination.

	Google Docs
PROs	It has a good WYSIWYG interface. Very intuitive, plenty of undos, etc. It supports a very impressive version of collaboration, where different people can work on a document together in real time. Authors can see each other’s words appearing in the document as they work in parallel, as peers. They can also see each other’s gestures (via the cursor). It keeps a doc’s complete history. You can even name particular versions of a doc to easily recognize them.
CONs	The code is proprietary. It supports a version of JavaScript that you can use to make extensions, but you’re SOL if you want to make a major mod to it. Only one version is rendered at one time. If you want to work off the version from three days ago, you have to choose it for rendering. But this deprecates the current version. If three people modified the version you’re interested in, you can render only one; the others are History.

rMake Is Born

In the end, we opted to create a new app we call rMake^∇ as an OSS platform that others can extend. There are several OSS editors that we can leverage for our UI and many OSS components and libraries that we can use in the making of rMake (e.g., diff).

No Trunk (Decentralized)

In rMake there is no trunk. Instead of trunk and branches, rMake has flows and every flow is persistent (e.g., fully rendered). Even if the co-authors agree to merge all their flows into one, the result is just a co-equal flow.

These flows are fully rendered and at any point in time, a reader would be able to see any. Perhaps one flow is recommended by readers more than the others, but all flows will still be around for readers to explore.

Authorship & Ownership

A fragment could be a phrase, sentence, paragraph, and even a word. Every fragment carries authorship and ownership.

Authorship and ownership can be unknown, marked as TBD. Authorship is usually known, but ownership can be more problematic to discover.
If ownership is marked as TBD, then anybody, say, PubCo, can claim ownership of a fragment and, assuming that they can prove it, PubCo would then be assigned as owner of the fragment.
Authorship means that co-authors are responsible for its content.
Ownership includes the power to decide on fragment merges.
Ownership does not imply exclusivity and anybody can copy any fragment in a flow at will. As noted, the fragment ownership goes along with it.
Others can create their own flows with fragments authored by somebody else, say, me. The resulting content would indicate me as a co-author and the person doing the modification as another co-author.
Using the RAD Distribution model, revenue from, for example, consumer purchases or licenses, could be distributed to co-owners as a function of their ownership of the complete work.
RADs account for level of contribution. The original author of the fragment could assign RADs to other co-authors or the whole thing could be automated based on, say, the number of words added.

No Permission Needed

Any co-author can copy a flow without explicit permission; in fact, anybody can do that. On the other hand, an author can easily find out every copy of her content ever made (i.e., even if it is a copy of a copy).

A co-author could make any and all of her flows unreadable to others. Otherwise, if you can read it, you can copy it.

Pull Requests and Merges

A co-author will need the agreement of a flow owner if she wants to have her work merged with his. How that happens depends on a discussion among the people involved.

Use Cases

1+1 = 2	When the content overlaps, one of us may create a pull request for one or more fragments. We discuss the differences, agree on how to align them, and our work gets merged. We end up as co-owners of any fragments that were modified by both of us.
2+1 = 3	Another writer joins us and starts to work off the backlog in a separate flow. She issues a pull request to merge her fragments into our flow. After some discussion, the fragments are merged into one. From that point on the flow is owned by all three of us.
2+1 ≠ 1+2	After working on my own flow for a while, I created a pull request for a flow owned by two co-authors. He wants to reject it but she wants to accept it. She stops contributing to the original flow, forks the content as a new flow, and starts contributing to it. The new flow includes the original content co-owned by the extant co-authors, my content, and new content that she and I create.
1+1 = 1	For whatever reason, I slow down or stop working on the project. My co-authors keep going strong and create a lot of content for it. Other co-authors join. That is fine. I continue to own the content I authored and co-own any content that I co-authored.

Flows

Flows tie together a number of fragments to make for a coherent reading. Flows are first-class objects, persistent and publishable. For example, assume a book project starts with two authors and ends with many contributors from different authors,

For example, these could be the flows in between,

This image shows six flows. FLow one is made up solo fragments. Fragments 1, 3, and 4 are by author1 and fragment two is by author2. The second flow starts with the same fragment written by author1, fragments 2 and 4 by author 2, and fragment 1 by author2. The third flow starts with the same fragment written by author1, the second fragment is co-written by author1 and author2, the third fragment is still the one written by author3, and the the last fragment written by author2. THe first two fragments of flow four are as before, but this time fragment 3 is written by author 2 and fragment four is co-written by author2 and author5. The first two fragments of flow five and its last fragment are as in flow four but in this flow fragment 3 is written by author5. The last flow illustrated starts with the same fragment written by author1, fragment2 is co-written by

For example, maybe @author3 stopped contributing after modifying chapter 3. Other co-authors, however, continue to move the content forward and their changes make @author3’s contribution obsolete. Or various co-authors make a few updates to my 4.0 fragment and then I make one last modification.

There will be the case where one or more co-authors go off in a different direction from the perspective of the other co-authors. In that case, the divergent co-author(s) would start a new flow with the content of the source flow and then add new content to it (i.e., This is conceptually similar to a fork of an OSS software project). They can create a Linked flow, where the untouched fragments are merely links to the original (i.e., Linked flows will reflect any and all changes in these fragments),

They could, alternatively, create a Copied flow, where every fragment is a static copy of the original fragment. Changes in the original fragments would not be reflected in the new flow.

Either way, authorship stays with each fragment, whether Linked or Copied. Content is owned by those who author it.

These flows are first-class objects. They are addressable, persistent, and each can be publishable separately. For example, I could post a URL to one flow (e.g., 1, 2, 3, 4) and you could publish another flow (e.g., 1, 2, modified 3, 4). Readers can choose to read one flow or another. Or they can jump from one to another, regardless of the flow they started from.

Of note, this could cause weird situations. For example, I create a flow about responsible gun ownership. Somebody else may fork it and use the statistics chapter to support reckless gun ownership. In this case, I could end up getting paid from sales of the “irresponsible” book. At first, I found the thought a bit distressing, but as Doug Kirkpatrick points out,

That might actually be a good thing because it would further empower the responsible writers to keep writing responsibly! And OPEN is kind of a binary thing – something is either open or closed.

If a statistics book chapter is OPEN, therefore, it is subject to being applied by individuals to arguments with which we may disagree.

I also think that books aren’t just about the writers, they’re also about the readers, who have some responsibility to filter the information (including statistics) they read and make self-informed (self-managed!) judgments about the veracity of that information. Statistics aren’t always the lovely, objective things we assume them to be.

How to Lie with Statistics</em>.^∇

Publishing

The mythical “book deal” includes an advance that a publisher pays an author when the book is just an outline. For well-known authors and brand names (e.g., ex-President Obama), that is still the case. The rest of us get, at best, a percent of sales minus all expenses, including returns,

In the rMake model, a Publisher could,

Negotiates a deal around a particular flow.
Make a deal around all existing flows.
They could even pay for preventing new flows for a period of time.

This is ripe for experimentation.

Use Modalities

Contributions

Contributions come in three flavors: suggestions, rewrites, and additions.

Suggestions	Typos, word replacements, very short rewrites.

Rewrites	A significant amount of content is rewritten or re-laid-out dramatically differently.

Additions	New content is added.

The different types of contributions must stand out and be visually distincts. Manipulating them must be intuitive (e.g., as implemented in Google Docs, suggestions can render a document unreadable with many strokes and modification, and comments can overlap suggestions and make them unreachable). It must be straightforward to convert a suggestion to a comment and vice versa.

Suggestions, rewrites, and additions carry authorship. When accepting any one of these, its authorship comes along with it.

Roles

Reader	Needs to, See the content. Optionally see a table of contents (collapsible). Leave a comment associated with highlighted text. Optionally see comments that others have left (collapsible). Leave edit suggestions. Share content, Where the URL points to the highlighted text. See and follow alternative content. For example, a button labeled “Alt Content” would jump to the alternative if there’s only one or show a pull down list if there's more than one. Or the button could open a side panel to show a short description of each version.
Writer	Needs to, Start in editing mode. It renders the same as reading mode, but it allows editing. Leave comments and edits assigned to a user (may be herself).
Co-Writers	Same as a single writer, but in addition they need to, Fork the whole book as a separate flow. Fork a particular fragment, be it a section or subsection, a paragraph, a sentence, phrase, or excursus.^∇ Create a Pull Request^∇ to, Hold the discussion about a merge. Record the final decision (to merge to not merge). Different versions of the content could invoke separate Pull Requests, Yesterday’s Pull was rejected because the authors agreed that more work was needed. Today's Pull request is accepted for merge after a short discussion that deems the new work as acceptable.
Editor	Same as any co-writer. All changes go into a separate flow. Authors are free to accept some or all of the suggestions.

Other Potential Features

Comments and Suggestions

Comments and suggested edits enrich a document, particularly when it generates a dialog among co-authors. The end result of a discussion may be that co-authors go off to create their own flows. And that’s good.

When that happens, the new flows will carry a copy of all comments and edits with it. If one author decides to remove some or all comments or reject the edits, then they still exist in the original flows.

Social Media

A la Medium, text can be pre-selected as “ready to post.” Clicking on that text brings up a, for example, Twitter or LinkedIn post window with the text itself and a URL to the quoted text.

Also, text can be selected and sent to other Social platforms, including a URL that points back to the text (i.e., a la Diigo).

References

An rMake reference can include text, URLs, or both, a la Kindle.

URLs can point to internal targets (e.g., titles, headers).

Paper

The rMake platform can prepare a flow for traditional paper publication. In particular, the platform will make it easy to convert references and URLs to footnotes or endnotes.

Advanced Readers

Support for Advance Readers, by creating a copy of the text whenever the Advanced Reader makes a comment or a change.

Search

In addition to searching text, support searching Comments, Suggestions, Images, Footnotes and Endnotes.

Citations

Support footnotes and endnotes.
Support endnotes at the end of a section (e.g., chapter), and endnotes at the end of the book. Any and all of them may appear in a book.

Image Source, Title

Support adding sources to an image, optionally with embedded URLs to its source.
Support adding titles to an image.
Support positioning these sources and titles as per the authors specs (e.g., top, bottom).

Bookmarks

It should be possible to add labels to a bookmark (e.g., “Start here”).
Highlighted text yields a bookmark that includes the start and end of the highlighted text. Title, subtitles, and headers always yield a bookmark.
Clicking on an embedded link would show you where it points to, a la Google Docs or where it is referenced from.

Templating

Authors can create a TEMPLATE.
A URL to a section in the TEMPLATE actually redirects to a child of the TEMPLATE or, in its absence, to the TEMPLATE itself.
Changes in the TEMPLATE affect all its children unless a child has explicitly blocked that action.

Views

A View defines how a user, whether reader or writer, sees the content. Some people like to start paragraphs with an indent, but others don’t. Some like more or less whitespace after sentences (e.g., double space, single space). Some like paragraphs adjusted, some like them ragged.
Views are first class objects and can be combined with any other first class object. For example, a View can be selected by a reader which incorporates her preferences.
Conceptually, there could be a View for the whole Flow, but another View for a particular module.
Parameters would include indentation, margins (all or individually as right, left, top, bottom), font family, font size, space after end-of-sentence punctuation (e.g., n-width, m-width, other size), etc. (I imagine this as a CSS parameter file).