
 I'm Building a GitHub for Writers - guynamedloren
http://madebyloren.com/github-for-writers
======
crazygringo
A lot of programmers already find it awfully hard to wrap their heads around
how git works. I can only imagine how hard it will be for non-programmers to
(it doesn't suprise me that the successful example used is written by
_mathematicians_ ).

HOWEVER, that doesn't mean it can't be done. In fact, if there are ways to
visually simplify git and make it more intuitive for non-programmers, those
techniques could wind up making git even better for programmers too.

I could also imagine a convergence of the git model and the wiki model someday
-- where anyone can edit (like Wiki), but where there are branches, merging,
etc. Obviously, a lot of internal wiki's don't need such complicated version
control, but for things like Wikipedia, it could be amazing.

I think there are a _lot_ of areas for working on writing collaboration --
group projects in school, business proposals, technical manuals, all sorts of
things.

And the main attraction for users over, say, Google Docs, is that _your
changes don 't overwrite others'_. The fact that your edits create a "branch",
that then others can accept/reject/modify/merge, is a vast improvement in
creative collaboration.

~~~
malandrew
Learn Git Branching did a really good job of making git easier to understand:

[http://pcottle.github.io/learnGitBranching/](http://pcottle.github.io/learnGitBranching/)

If you take that approach and update with precise but plain english vernacular
(redundant?) and domain specific examples, then you are halfway there to
making it understandable by regular people.

The most important thing to help people really get it is to promote small
commits to their work. The real value of git only makes sense when you start
making small commits. Having worked as an editor in a past life, having
something like cherry-pick and interactive rebase would have been most dope.
In a way, maybe editors are the best audience for driving adoptions among
writers in general. For professional editors, version control is a painkiller.
For writers, it is a painkiller if the writer is an obsessive editor. For
those who write and commit once, but don't go back and review commits and
refactor, it doesn't provide much value.

Think about how Apple Time Machine made a stab at operating system backups and
snapshotting. Was it perfect? No. But it was a step in the right direction.

Loren and others may not solve all the problems right out the gate, but they
will lay the groundwork for new approaches to teaching version control to
writers and other audiences.

~~~
AlexSolution
Love this site. Hoping people contribute a few more lessons to it in the near
future.

~~~
xxbondsxx
Thanks Alex! I'm working on some lessons around push / pull / rebase right now
that I think will be super helpful for learning the next steps.

Progress has slowed a bit since work has ramped up, but now that intern season
is over I'm expecting to make some progress

------
babuskov
I was looking for something like this. I'm planning to write an epic sci-fi
novel and make it available under some open license (Creative Commons BY-SA
probably). Since I'm not a native English speaker, I'm hoping those who are
would jump in and help me perfect the text.

My final hope is to see a Hollywood movie made out of it one day, because many
recent SF movies lack good story.

My other idea is to make the story branch into different directions. I would
write the main storyline, but another writer could come and fork it at some
point. The reader would be left with a choice at some point: would you like
this character to take that decision or the other - and after choosing, the
reader could read the forked variant.

This is the first time I'm publicly writing about this idea. I'm still
undecided what technology to use to create it.

~~~
Blahah
Git branching a storyline is an awesome idea.

I'd love to know when this book gets off the ground - I enjoy both sci-fi and
correcting other people's English.

~~~
babuskov
Thanks, I'll take you up on that. I assume that the e-mail in you HN profile
is valid?

~~~
Blahah
Yup - look forward to your email.

------
tptacek
This is sort of what Nate Kontny is doing with Draft, which I like kind of a
lot, much more than I expected to.

~~~
Shank
My biggest issue with Draft is consistency in behavior. Personal anecdotes are
frowned upon here, but for most of last week the ability to export files
wasn't working at all for me. When I'm dealing with Markdown, this is the last
thing I want to happen.

I much prefer a system that's geared to projects and not specific types of
document too. For example, if this supported housing a collection of documents
and an image or two - with changes able to be made on each file, it would be
amazing. Google Docs I edit with others quickly tends to devolve into three
different types of sharing/permissions issues, and I'm left frustrated or
wondering why some people can access one thing or another.

There's definitely room to innovate here.

~~~
guynamedloren
> _I much prefer a system that 's geared to projects and not specific types of
> document too. For example, if this supported housing a collection of
> documents and an image or two - with changes able to be made on each file,
> it would be amazing._

Nailed it. That's what I'm building :)

------
dylandrop
This is interesting, but I think it kind of fails to take its audience into
consideration.

1) It assumes writers write like programmers code. This isn't true. At least
with scripts, what typically happens is the writer will write an entire
script, send it to their boss for revisions, and then rewrite it. They would
consider it a pain in the ass if they had to make "commits" for every page
they wanted to add, and especially if their bosses had to review each change
(mostly because bosses are executives who just want to leave their mark by
making unnecessary changes on things).

2) In either book or script writing (or whatever) small grammatical changes
are unimportant, and there will be way more of these than we would care to
look at. Who cares about reverting a change of "its" to "it's"?

I see this kind of thing as being useful for writing an informal,
informational book in the form of an extended blog post (see
[http://gettingreal.37signals.com/](http://gettingreal.37signals.com/)) but
otherwise, I can't really see it being that useful for professional writers.

Also, something that I think would be REALLY useful (that I'm honestly
surprised I haven't seen is a Final Draft - meets - Google Docs (screenplays
editable by multiple people via online, all stored online). Dunno if anyone's
seen anything like this.

Sources: My dad is a TV writer.

~~~
cauthonLuck
Scientific writers do write like programmers code. There are as many as ~15
authors on a paper. The scientific paper has intensive markup, often in Latex.
And collaborative writing like GoogleDocs doesn't work b/c 3 different authors
will make changes to the same sentence and you need to be able to see all
three changes next to each other. Not to mention figures, equations, etc...

MS Word and Libre office aren't powerful enough for scientific writing and
aren't universally embraced or consistent across operating systems.

Github for writers is desperately needed. Draft doesn't do nearly enough

Source: physical science graduate student

~~~
natejenkins
Hey, I'm working on a similar project for scientific writing. You can find the
link in my profile along with my email.

We have had success with large collaborations working on it, 15 authors should
not be a problem.

Check it out and feel free to contact me.

------
jedc
Is it just me, or are there a number of fairly high-profile writing tools that
have launched recently? The ones I'm thinking about:

    
    
      * Draft http://draftin.com
      * Editorially http://editorially.com
      * Quip http://quip.com
      * Loren's Penflip http://www.penflip.com
      * Google Docs (obviously not new)
    

A lot of thoughts running through my head, including that finally products are
being built from the ground up both for collaboration and for mobile/tablets.
(And that this appears to be an early sign of the end of Microsoft's dominance
in the office productivity software world.)

~~~
Myrmornis
Are any of these projects aiming to interface well with MS Word or OpenOffice?

~~~
sdoering
Well you could use pandoc [1] for creating MS Word or other file-formats. As
far as I know MS Word is still the choice to use for novelists, when it comes
to giving test to editors and a like.

So pandoc could be used for transforming a text into many different formats
(even ebook formats).

Might be an interessting thing to look at for the creator of "git for writers"
;-)

[1]: [http://johnmacfarlane.net/pandoc/](http://johnmacfarlane.net/pandoc/)

------
scottfr
I'm currently using GitHub to collaborate on writing a book with a non-
technical coauthor. Generally it works great, but there are two key issues:

* Changes are tracked by line which is equivalent to a paragraph in a book. If I go in and add a comma to a paragraph and my coauthor simultaneously changes a word in that paragraph that can create issues.

* Errors are very difficult to solve for my coauthor. When Github Window's app encounters an error, it basically says "Just open up the command line and you should be able to figure out how to solve this". Of course this isn't feasible for a non-technical audience.

If your product can fix these two issues (which it looks like it is trying to)
it could be very valuable.

~~~
nadaviv
> Changes are tracked by line which is equivalent to a paragraph in a book.

When using Markdown, I usually split paragraphs over multiple lines (usually
between sentences) which makes diffs much easier to read, while still
rendering as a single paragraph.

~~~
vidarh
Same here. "Single line paragraphs" are a pet hate of mine - they have no
place in plain text files even if those files are intended to be post-
processed.

~~~
tasuki
I'm still undecided on this. Say you have a long paragraph and have to add one
word at the beginning. You have two options - either rewrap and introduce a
silly diff, or don't rewrap and exceed your chosen text width.

Single line paragraphs don't put such a difficult choice in front of you. If
your diff software is any useful, it'll highlight your change within the line.

~~~
gknoy
Perhaps you could have a special kind of commit, a "text-rewrap" commit
(similar to merge commits), which might let your diff presentation tool
alternate between diffing lines, pararaphs, or the like. I agree, the
presentation layer really needs to be as granular as your editing team needs
to be. I __really__ like how Github shows the differences within a line that
is different.

------
AndrewDucker
What I mostly want, when writing collaborative documents, isn't a git
equivalent - it's a code-review equivalent.

I want to leave comments on individual words, sentences, paragraphs, etc.,
with suggestions for changes. And that's something that git doesn't allow,
because the smallest change you can comment on is a file, with no ability to
comment on specific parts of it.

~~~
guynamedloren
Git doesn't support it, but GitHub does. You can comment on individual lines
via GitHub. I'm going to do something similar - maybe on a more granular level
(words/sentences).

------
begriffs
I think the guys at Github do want to help non-technical people learn to
collaborate with git in areas like education, government, and literature.

Check out this interview where one of the Github trainers, Brent Beer, talks
about these ideas. You might want to get in contact with him.

[http://blog.begriffs.com/2013/08/an-interview-with-brent-
bee...](http://blog.begriffs.com/2013/08/an-interview-with-brent-beer.html)

~~~
guynamedloren
> _I think the guys at Github do want to help non-technical people learn to
> collaborate with git in areas like education, government, and literature_

Yep, they're doing it, just not quickly enough :)

Neat, I'll check out the interview. Thanks!

------
stared
Take a look at "Why use version control systems for writing a paper"
([http://academia.stackexchange.com/questions/5277/](http://academia.stackexchange.com/questions/5277/)).

When it comes to diffs for text, just add "\--color-words":

git diff HEAD~1 --color-words my_file.md

But I agree with other stuff, that for non-techies Git + GitHub may be to hard
to start.

------
joshdotsmith
I know that Michael Hartl of RailsTutorial is working on something very much
like this, but will be a full end-to-end product including things like sales.

I can't wait to see what he comes up with.

------
bliker
How are you solving the diff problem? Word based diffs tend to be jumpy and
hard to follow. On the other hand line based diffs do not work well for text
(prose).

~~~
guynamedloren
Yeah, prose.io uses word diffs and it's definitely hard to follow.

I'm doing 'fragment diffs' (doesn't really have a name) - but basically, all
the text is displayed as you would read it (sentences and paragraphs), with
diffs displayed inline and colored. Added content in green, removed content in
red - doesn't matter if it's characters/words/sentences/paragraphs - it all
works.

Screenshot is not the best, but something like this:

[http://www.flickr.com/photos/madebyloren/9620674181/](http://www.flickr.com/photos/madebyloren/9620674181/)

~~~
philsnow
Don't know if you've already thought of / planned this, but please please
implement a side-by-side diff view.

Code is easy enough to read in a unified diff because lines are usually short
(unless java). Prose flows a lot more fluidly, and there is no formal grammar
for human language. I have had the displeasure of having to read "redlines"
(prose with inline diffs marked in red strikeout) and I find them completely
impenetrable.

------
mallyvai
From @kmatzen's comments on Authorea.com: " What do you get when you combine
authors with gonorrhea? Authorea!

I like it! There are two things I would still like though. One would be page
rendering in the browser. We often have to iterate several times on a paper
adjusting figures, text, padding, etc. to get everything to fit within the
page limit. I could write the paper in this and then export it to tex, but
that defeats the purpose. The second thing is support of popular LaTeX
packages. It looks like I can upload arbitrary tex documents, but that's going
to get messy if I have to upload the same packages for every paper I'm
writing.

We use github for our papers right now. Less than ideal. "

~~~
natejenkins
What can I say? Naming is hard. We initially thought to ourselves, "Spreading
science should be fun and intuitive, like an STD. And it should be hard to get
rid of." Thus Authorea was born.

Have you tried our pdf exporter to check page length? We are trying to build
it out to where you, as a user, don't have to worry about packages. If there
is a journal you would like to submit to and we don't currently have the
journal setup as an export template, please contact us and we will be happy to
add it.

It's funny how authors worry so much about page length and figure placement,
and then the first thing a journal does is remove all of the formatting the
author has put in place.

------
mehulkar
What about draftin.com? I use that already and I like it a lot.

~~~
guynamedloren
Big fan of Draft (and Nate). It's got the version control part down, and I
think it works well for gathering feedback on blog posts and other short form
content, but it isn't designed for longer form content as far as I can tell.
It's also missing the community aspect that GitHub has, which is huge, as well
as features that would make writing an ebook or textbook feasible. Definitely
a great tool though.

~~~
spartango
Any reasons not to work with Nate? It seems like the social stuff could be
built in tandem with his strong editor.

------
ozh
I'm a little late in the party but I wanted to express my feelings anyway. I
wrote a book with 2 other authors 2 years ago, and would have LOVED a tool
like this. Going over Word documents in revision mode was a colorful
nightmare. In general, having to work with Word was not the ideal stuff
anyway.

To my point: to be totally useful along the whole typical writing process with
traditional publishers (authors -> technical review -> authors -> editor
review -> authors -> punctuation/misc review -> authors -> editor) you'll need
at some point to export as Word documents. Ideally, collaborate in Git like
environment, export as Word, receive a new Word with all those colored
revision and import into Git like stuff.

------
jawerty
I think this is a really interesting idea; however, I don't think it's a very
good method to build it as 'Github for Writers' since coding and writing are
two very different processes. For instance, writers often create their work on
their own instead of with multiple contributions. Contributors is more of a
code project attribute, for anyone who knows how to program well can
add/modify code while not anyone who knows write well can add/modify to a
story.

It is true that writers need editors but editors are certainly not writers. If
there was a system where all of the contributors acted more like 'editors'
rather than writers than I personally think it would be an awesome version
control program.

~~~
RougeFemme
I think this may be true for fiction (. . .writen often create their work on
their own. . .not anyone. . .can add/modify a story), but I think it's a great
idea for non-fiction, such as the textbook and research paper examples that
the OP cited. Other examples include user or technical manuals, requirements
documentation. . .The team members are often more akin to contributors (code
or otherwise) than to editors. Individual but interlinked units have to come
together to form a whole.

~~~
gknoy
Absolutely. My wife's job as a professional editor involved editing hundred-
page documents, often with more than one author. A tool which made version
control simple, yet writing easy, would be a godsend.

The down side is, many such organizations (e.g., military) have standardized
on Word, which is terrible for collaborative review, editing, and version
control of long documents. (Of any documents?) She would have been extremely
happy had her employer allowed them to use LaTeX or similar.

~~~
guynamedloren
> _Absolutely. My wife 's job as a professional editor involved editing
> hundred-page documents, often with more than one author. A tool which made
> version control simple, yet writing easy, would be a godsend._

I hope you signed up - I want to that editing process easier!

~~~
lutusp
> I want to that editing process easier!

I believe that sentence no verb.

~~~
guynamedloren
Ha, woops.

------
chalst
I'm familiar with similar workflows. Last week, I edited via a (private)
Github repo with a scientist client who use Emacs/ org-mode/ ediff, authoring
.org files, editing using Git staging to create change sets and inline \NB[]{}
commands to annotate changes, and ediff/git-merge to step through and resolve
changes.

Some observations:

1.Ediff is a nice tool to use for resolving Git conflicts;

2\. Org mode works very well with this workflow, provided you use one
paragraph per Unix line;

3\. Latex generation can be very nice from org-mode sources, and the org-mode
-> Latex exporter allows a nicer separation of content from presentation than
you get with vanilla Latex.

I'd love to hear of anyone who has success with a similar, but vi-based
workflow.

~~~
cauthonLuck
I use a similar setup with vim+latex+git for chemistry articles. It works
amazing for me. I feel like it is the most powerful presentation setup and
most efficient editing setup currently available.

I break sentences by ending with two spaces. (this doesn't matter since Latex
is markup) The only issue arises when ideas span across multiple sentences,
but I believe there is a flag for controlling the number of lines around a
diff. (sorry, I'm new to git) But this sort of proves the point that an easy
wrapper for git should be created for scientific writing.

The two main problems I have are: 1\. adoption by collaborators (they can't
surmount the learning curve) 2\. diffing sentences is very different from
lines of code

~~~
chalst
Typical Org-mode code diffs better than typical Latex code. This is a serious
argument in favour of authoring in Org-mode and using its Latex export
facility.

------
uams
The key to this one will be figuring out what features of git (and in
particular github) will make it successful in other verticals.

I wonder if some key CS concepts are so fundamentally ingrained, but that
writers think about their work flow differently.

------
Doctor_Fegg
Great idea. Yes please!

But Markdown as UI... is less than ideal. It's great for hackers, but there's
already a GitHub for hackers, and it's called GitHub. No matter how much
prose.io prettifies it, you still get those damn asterisks all over the place.

Personally, I write in TextEdit, Helvetica 12pt. That's not a universal
answer, but it works for me. (Previously I used MacWrite Pro, ClarisWorks and
Word 5.1 at different times, but the basic appearance was the same.) Anything
that makes a bold word look like "* * this * *" breaks 20 years of habit, and
I won't do it.

Markdown as backend storage, fine. But not as the primary editing interface.

~~~
fian
At work we are trialling Lyx + Subversion for collaborative creation of
developer documentation. The stored data is in a text + markup format which
allows for easy diffing. Lyx being a layer over Latex means we can easily
transform into a wide variety of formats, but mostly we output to PDF and
HTML. Subversion was chosen as we already had a server available and there
isn't really the same need to branch/merge documents compared to code. Writing
in Lyx took a little time to get used but I definitely feel more in control
that when trying to wrangle complex docs in Word.

~~~
kraymer
I used to write my documents in Lyx too but spreading the tool amongst my
colleagues involved a lot of evangelism. Markdown is a backend storage easier
to adopt as developers are used to it (stackoverflow, github) but it produces
output for the web : no pagination, header/footer, etc. Throw pandoc+tex
template into the mix, and it starts to get really interesting : a quickly
hacked markdown file transforms into nice pdf will all needed attributes. But
why stop there? Now that you have a build process, move it to a server and add
some hooks to injects traceability infos (author, last edit date, commit
hash...) into the generated document, etc...

I went down this road, and it works surprisingly well. If you're trialling
different solution for writing technical developer documentation, see a more
precise description of the workflow that I pushed on my blog yesterday:
[http://kray.me/pro/doclegit-git-documentation-
server/](http://kray.me/pro/doclegit-git-documentation-server/) (sorry for the
copy quality, english not my first langage, corrections by mail are welcomed)

~~~
fian
Interesting. When we set this up we looked at maybe adding an automated build
(transform) step on commit via our CI (Jenkins) server.

While the software developers are comfortable learning and using Markdown or
other markup syntaxes, I eventually would like to spread this approach to
other technical people in the company. In previous attempts at teaching basic
scripting (Awk, Ruby, Python) to engineers who are comfortable writing complex
logic operations in Excel and who can dabble in VBA - I found a lot of
resistance to the idea of learning a new syntax. So I expect the evangelism
required to get these colleagues to write in Markdown will be greater than
showing them Lyx, which at least looks like one of the editing modes in Word.

~~~
kraymer
I thought the main technical hurdle (for not dev crowd) in my current workflow
was git as there exist a lot of good Markdown editors on all platforms ;)

------
GrinningFool
Is this going to be focused on those who use latex and markdown, or the the
broader audience of 'people who write'?

If the latter, you run into a problem pretty quickly - MS Word. It's still one
of the most popular document editing tools out there. More recent versions do
store content in zipped XML, but are you willing to put the work into parsing
that content at a level sufficient to let it integrate into the kind of flow
you discuss?

(EDIT: That said: if your target is those creating text-based documents, then
I think this is an excellent idea. )

------
cauthonLuck
How many of these options penflip, draft, etc are actually open source?

I'm looking for very specific features on the level of Latex libraries that
would never make it into a for profit application.

------
bambax
This is a fantastic idea, beautiful and beautifully simple. Of course, one can
think of a million objections to its success, but I really really hope it
succeeds!

------
nwhitehead
An idea is to think about rendering/typesetting as a feature. For many,
getting an environment set up to turn the project files into final files of
whatever form is a huge barrier. It would be great to have a bunch of back-end
rendering be just a click: Markdown->HTML, Markdown->PDF, Markdown->epub,
Latex->PDF, Latex->HTML.

~~~
cauthonLuck
especially when you throw in citations for scientific articles. Which often
require compilation of the citation database, citation order, and citation
insertion. Adding 3 more steps to the process.

I've recently switched to papers to help with this. It seems to have a strong
community and supports both MS word, libre office, and vim. Jury's still out
though.

[http://www.papersapp.com/papers/](http://www.papersapp.com/papers/)

------
FiddlerClamp
Have you asked a representative sample of writers whether they write this way,
and would like to use your site to write this way? Outside of business,
collaborative writing seems to be pretty minimal (I say this as a novelist)...

Also, if there could be some cross-compatibility with MS Word's Track Changes
(I know, I can dream...) that would be great.

------
lizelfman
As a writer I'd be glad to use something like this. I'm working on a book with
the founder of a non-profit in DC, and it involves a lot of sharing articles,
trading thoughts, and sending documents. We've been using Honey.is which is
nice for small businesses but just not as collaborative as we need it to be.

------
rrhoover
Ironically, I posted a call to action to build a community for writing
together. Very curious to see how Loren's project does and how it compares to
Draft and others.

[https://medium.com/writers-on-
writing/920214571e3d](https://medium.com/writers-on-writing/920214571e3d)

------
decadentcactus
This might be useful for contracts, as well. Editing points and having
history, being able to comment on specific parts etc.

Not 100% sure on how to solve the "legally binding" part if the other party
declines digital signatures, but it'd be a good way to get the contract
written and agreed on.

------
hyperpape
I wonder if you might prefer something like Darcs to Git. I've heard a lot of
amnbivalence about Darcs as a practical software project (just seems to be
losing momentum, and it has never matched Git for speed), but I wonder if the
model is more apt for writing than Git.

------
dbspin
Can't emphasise enough how important offline editing would be for something
like this. As a professional writer (whose co-written a book), you can't rely
on always having internet; but you always need to be able to work on your
current project.

------
gt5050
This sounds great.

I am also working on something similar called Papyrus. It lets authors create
and edit ebooks simultaneously.

[http://papyruseditor.com/en/home/collaborate/new](http://papyruseditor.com/en/home/collaborate/new)

------
pavanred
This might be naive, but don't authors use Latex to write? So, in a sense why
can't they use github as it is to collaborate on writing?

(I guess it goes without saying, I do not have any experience or knowledge
about the writing process authors follow)

------
felipebueno
It's sad for me to see what you are doing because I had the same idea like 5
months ago. But I'm not that good on putting ideas into actions so it didn't
go that far. :(

That'd be an awesome tool for witers, bloggers, editors, etc.

Keep up the good work! =)

------
zfrenchee
I wonder if Github is working on something like this.

I'm sure they're familiar with the idea and they seem like the best team to
bring it online. They're still a startup looking for growth opportunities:
this one seems obvious.

------
diziet
Do authors really collaborate as much as developers do? Wikipedia is an
example of people collaborating on writing something, but the subject matter
is quite different from the kinds of writing that gets done.

------
SunboX
> What's so awesome about GitHub?

It isn't all reasons mentioned in this article ... the most awesome about
github are the developers. This is the biggest reasons why a "github for
writers" could fail

------
srameshc
I am trying to do the same. I never even thought about sharing this concept
till I could launch. I know for sure this a great area to work on and it will
make a huge impact for collaborative story telling.

------
albertoperdomo
Just a heads up: I just tried to signup for the newsletter and got a nasty
Rails error page (500). It turns out Iwas browsing with JS turned off (using
NoScript). It worked fine after activating JS.

------
victormier
As I was reading all these words about project collaboration I started getting
more and more excited about the thought of myself collaborating in your
project. Until I saw it was not open sourced...

------
based2
Wooki* is a smart tool to write documents. It let you publish them and get
reviews

[https://github.com/spreadthesource/wooki](https://github.com/spreadthesource/wooki)

------
agentultra
Github for lawyers, laws, court records, etc. I wonder how the lobbying
industry would change if there were highly-public records of everyone's
additions to a bill.

------
theorique
Github works on source code, which is text files.

Writers work on English text (or other languages) which is text files.

What does this do that Github itself (or equivalent - bitbucket, etc) does
not?

------
gprasanth
Just today, I was checking out the JS API wrappers for Github API v3 and I
found Github.js. There, I discovered this site called prose.io

Check it out! It's awesome!

------
RazerM
This site doesn't work very well on mobile
[http://imgur.com/opmjUGn](http://imgur.com/opmjUGn)

~~~
guynamedloren
Ah I know.. I've been meaning to fix that.

------
hrjet
Could this be used for other text-based documents?

I am thinking of accounting systems such as ledger-cli which let you keep your
accounts in plain text files.

------
rrrene
So I get the vibe that this will never be open sourced but is a side-project
of yours that (should it come to fruition) will be run as for-profit.

Am I right?

------
user1241320
I thought [https://poetica.com/](https://poetica.com/) was doing just this

------
malcolmmcc
See also [https://www.scigit.com/](https://www.scigit.com/)

~~~
michaelbuddy
link fails. no https on that site.

~~~
malcolmmcc
huh, both work for me.

------
bayesianhorse
I always thought "forking" in writers is sort of frowned upon...

~~~
guynamedloren
Just like 'forking' code was frowned about before open source software came
about ;)

~~~
Thrymr
> Just like 'forking' code was frowned about before open source software came
> about ;)

Long after that, in fact. Forking an open source project was a desperate
measure to free it from unresponsive/difficult/differently opinioned
maintainers, that could leave a rift in the community for years (see
Lucid/XEmacs). GitHub made forking something that was normal, common and
expected.

------
guard-of-terra
The idea is terrific but focus is all wrong. Writers don't need branches. They
don't code features in. Hell, most developers don't do stupid updates-on-
branch-then-merge-merge-suffer-merge-curse-merge commit accounting.

Writers usually write alone, what they need is: A (desktop) tool with basic
WYSIWYG markup (paragraphs, bold/italic, that sort of thing) with version
control, visual diffs, export into common formats. Maybe a pull request or
two.

~~~
cauthonLuck
Scientific writers do need branches. When there are 10 authors on one paper
all suggesting different paragraphs/figures/equations at different times.

------
thenerdfiles
Just re-purpose git-flow with a "writing/publishing" namespace:
[https://github.com/nerdfiles/Concept-of-Flat-
Design#adaptati...](https://github.com/nerdfiles/Concept-of-Flat-
Design#adaptation-of-git-flow)

    
    
        master   <->  publication
        develop  <->  draft
        feature  <->  chapter
        release  <->  edition
        hotfix   <->  redact
        support  <->  copyright

------
frozenport
We edit research quality publications on Bitbucket. So Git already works for
writers.

