Also, my experience with Gittip when I was working with them, was that when listening to technical people explain it to non-techies people, having "Git" in the name works against you -- your best early proselytizers, the geeks, misunderstand the project's scope and goals due to the git-based reference point, and so explain it to new people as if it's a tech-centric thing. ie. It misinforms the same technical people who you're hoping will be spreading the word first, and they spread that misinformation to non-technical people, possibly discouraging them from investigating "that technical platform for geeks"

From the perspective of a non technical person the name 'GitBook' has even worse implications.

'Git' is a common insult in British English (being short for 'whore's get', i.e. an illegitimate child born to a prostitute). This may possibly reflect some private humor on Linus Torvald's part, since Git is putatively the 'son of a Bit[ch]keeper'. The term is used to indicate someone foolish and obnoxious. A non programmer unfamiliar with version control would hear something like 'AssholeBook'.

My thoughts exactly. The larger target market here is authors in general, with tech-savvy git users who also happen to write books as a much smaller subset.

It might behoove you to hide git in the background, as I suspect they do here: https://draftin.com/about

I think it doesn't really hurt, on the contrary, because of the name it might attract the _techie people_ and become the de facto publishing platform for all sorts of technical books.

Outside of tech, people are going to interpret 'git' not as version control software, but as a mild insult.

I hadn't thought of that, but upon reflection perhaps the 'For Dummies' has paved the way and people are more willing to accept mildly offensive book publishers/titles ?

I suppose TWiT TV also does fine.

Very few non-developers are going to use git unfortunately, so I doubt they are limiting their market.

Pure git directly, no. But a nice GUI system with git (or another VCS) under the hood could work quite well. People in the publishing industry at least already understand the concepts of versioning, diffs and merges, it's just that existing tools are optimized for code, not text.

That's part of it, yes. But code at the end of the day is just text, and at least the github interface is able to do word-by-word diffs. That ought, in the end, to be enough. The other issue is that non-technical people, in my experience, prefer to do their writing using software that does not bounce out VCS-friendly files, eg Word. Also, the terminology of git is somewhat abstruse to the novice.

It's a shame, because I can anecdotally think of one or two occasions where decent version control would have really, really, really helped in managing publications.

It starts with things like fixed-with fonts in the presentation. Great for code, really annoying for long texts. There are enough editors that still do some correction passes on paper, because it works better than spell-checking hundreds of pages on a screen.

I don't think many people are particularly attached to Word, it is just the most common thing that does what they expect. But similarly, tools would probably need at least some WYSIWYG-features. Like a simplified Word, with more sensible back-end formats and the ability to do diffs and merges also in this mode (similar to the change-tracking features in Word). If it is professionally published, complex layouting is done in different tools like Adobe InDesign anyways, so it doesn't need to be able to do much in the way of that.