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 |
|
CONs |
|
MediaWiki | |
PROs |
|
CONs |
|
Google Docs | |
PROs |
|
CONs |
|
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 |
|
---|---|
2+1 = 3 |
|
2+1 ≠ 1+2 |
|
1+1 = 1 |
|
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,
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. ∇ 
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,
|
---|---|
Writer |
Needs to,
|
Co-Writers |
Same as a single writer, but in addition they need to,
|
Editor |
|
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).
ENDNOTES
-
AEON. How Aztecs Told History. <https://radicals.world/pWo2WK> (alt, <https://diigo.com/0salwc>)
-
Git. <https://git-scm.com/>
-
MediaWiki. <https://www.mediawiki.org/wiki/MediaWiki>
-
Source Control System. <https://en.wikipedia.org/wiki/Source_Code_Control_System>
-
For more information, see Markup <https://radicals.world/59k36j> (aka, Markdown <https://radicals.world/Dbg4hm>).
-
Wikimedia documentation for developers. <https://mediawiki.org/$hellip/How_to_become_a_MediaWiki_hacker>
-
How to Lie with Statistics. <https://www.amazon.com/How-Lie-Statistics…>
-
Definition of “excursus”. <https://www.google.com/search?q=excursus&oq=excursus>
-
Definition of “Pull Request”. <https://en.wikipedia.org/wiki/Fork_and_pull_model>