It really is wonderful to work on documents with git and markdown is the perfect pairing of text format. There seems to be a huge opportunity waiting for someone to make a GitHub marketed to non-techie writers.
if you already know git (or github), it'll work for books.
but i doubt it's the best change-tracking system for them.
too much irrelevant crap, and it doesn't cut to the heart
of those things that actually need to be done for a book.
plus, most writers will never slog through learning github.
to make a system that is writer-friendly _and_ does what
a book-writing change-tracking system ideally _should_ do,
you'd have to hack github so much that -- in the end --
it would have been order-of-magnitude simpler (and better)
to program a purpose-built system instead, from scratch.
and yes, i told loren this from day one.
he didn't believe me then.
but if you ask him now, i'll bet he won't be quite so sure.
and by the time he's done, i have no doubt he will agree.
What you say is interesting, but how much time would he have lost before he could launch if he had to write a system from scratch?
On the other hand when using something ready like git allowed him to launch quicker. If he gets traction he can always write a new system later, if not then he has saved up on a lot of time.
perhaps you meant penflip's loren, not the original poster?
if so, then yes, what i'm saying exactly is that _loren_
could have saved himself time and trouble, in the long run,
by coding a purpose-built system, instead of hacking github.
what it would've cost him, however, is the huge "jumpstart"
he received by proclaiming his goal as "github for writers".
the kneejerk response to that, from the tech circles, was
something that created huge word-of-mouth and mind-share,
not to mention a great starting user-base, of technoids.
but that was months ago, and now there's some sense of
"whatever happened to penflip?" and when he goes out to
sell the system to writers, the "github" label will not be
a benefit at all. (if anything, it will be a liability;
but i think in general writers are fully unaware of it.)
all of this is my opinion. you, like loren, may disagree.
I write all of my internal documentation in Markdown and then use a pandoc script to convert it to offline PDFs, rendered HTML, and break out internal vs. public facing documentation.
