This is pretty interesting. For the book I'm co-authoring at the moment[0] I ended up putting together my own toolchain, including:
1. A dead-simple web IDE for asciidoc with live preview[1]
2. A script for checking for common AsciiDoc mistakes (e.g. an unterminated table will mess up all text following it).
3. A script which enforces the house style.
4. A makefile which runs docker (of course) to build the book with Manning styling.
5. A buildbot configuration on my server to run 2, 3 and 4 above on `git push` and move the generated pdf and docx into a directory served by nginx.
Though it may seem like a lot, this investment has been totally worth it - the ability to push a change and be viewing the updated pdf in ~1 minute is very liberating. I can't imagine what it'd be like to not have this kind of thing in place. I can share some more of the above if there's interest.
If you're ever thinking of writing a book yourself, I'd highly recommend making the investment into a process like the above (or a tool like GitBook, though I've never tried it and it seems to be more than just a build tool) so you can get the boring stuff out of the way and focus on what you want to be doing - writing.
I've written a book for Packt, and I'm in the middle of another - I'd kill for a Markdown converter for their Word format. Any chance you've open sourced it?
At present it uses asciidoctor[1] to go from asciidoc to docbook, then to .docx via pandoc[2] and .pdf via a Manning-provided tool (for styling reasons).
pandoc is pretty incredible. As you can see from its page, it can produce epubs and many other things - it's likely that with pandoc and a docbook file you can build a pipeline to take you wherever you need. For your purposes, you'd probably go from EPUB to kindle with KindleGen.
Hi I'm Aaron, one of the GitBook co-founders checking in.
You are giving great feedback and I'm more than happy to answer any questions you have.
BTW, in case some of you missed it, we're a big believer in open-source, in fact our book format and toolchain is open: https://github.com/GitbookIO/gitbook
This allows us to build better publishing tools together, no vendor lock-in and developers can build plugins to extend GitBook's features, here's a few: http://plugins.gitbook.com/.
I'm using gitbook to write a book currently (so I'm biased), but its an excellent platform for writers (especially those familiar with git). My best bits:
- Most of the product is open-source, which means I can tinker with their publishing platform.
- Version control
- Markdown support
- Mailing lists for readers (so you can send email updates)
- Support for donations and selling (I'm not using it, though)
- A traffic email sent every week
- Builds are pretty fast
- They even offer an educational discount on the pro plans if you ask nicely.
A few issues I've faced:
- The traffic stats are not realistic. It counts page loads, which are down by a factor of 2-3 as per my google analytics. Also, the country demographics are very clearly wrong (unless there is a readership of my book in Philippines that I don't know of)
- Landing page customization. They do have a few options, but I'd like more options
If there is someone who has tried both softcover.io (by Michael Hartl) and gitbook, I'd like to hear their thoughts.
Really interesting idea. I think this has the potential to grow into a real publishing platform, but also think that their name might hurt them. "GitBook" is very techie, and the name and the git-geared UX might be a hurdle towards moving past early adopters.
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.
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 ?
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.
Does this support inlined math formulas? This feature is very important, especially for a lot of technical writers. If it is present, then advertise it on the front page.
Yes, it supports inlined math formulas, through Mathjax (and KaTeX). It the upcoming 2.0.0 release, we actually render mathjax formulas to SVGs & PNGs so that they are visible in PDFs/EPUBs/Mobi.
Pricing model doesn't make a lot of sense to me. Just charge royalties for books sold. Why charge per month at all? If worried about many people starting books and never publishing then a small annual free should be enough to weed those out.
> Just charge royalties for books sold. Why charge per month at all?
Because almost all independently published books sells almost no copies, so there would be no revenue stream. The lack of sales is not a knock at indie publishing: there are plenty of reasons to publish a book other than making money. But it makes it difficult for services to make money off of them unless their incremental costs are negligible.
From an author's perspective, the monthly charge seems problematic. Why pay someone a per-month charge for a book that you wrote last year? Much simpler and cheaper in the long run to generate an e-book using Sigil or similar, and put it up on Amazon for free.
I'm a lousy judge of business models but the intersection of people who would use a service called <em>git</em>-anything and people who aren't tech savvy enough to generate their own e-books or PDFs seems very small. Sigil in particular makes e-book creation trivial.
Comments here suggest people are using the service and pleased with it, but it seems very expensive for a relatively small increment in convenience.
I've been using GitBook since the early days, and it has improved significantly in a relatively short amount of time. The web-based book editor is phenomenal, and it is perfect for creating documentation and lesson plans for students. I've been pointing every teacher I meet toward organizing and sharing their written material with markdown on GitBook.
Nice idea, but I'm getting so sick of seeing just-another-signup-form again and again and again...
Instead of offering the next useless service I would be better off performing myself, someone really should fix sign-ups (i.e. making them obsolete). That would really be progress for a change.
As for authoring, you could also use a decent SCM instead of git for versioning your texts. After all, the workflow model of git is hand-optimized for open-source software development which has nothing to do with book authoring. You would be better off with a centralized repository in typical cases. But git is all the rage now, no matter whether it's actually the right tool. Maybe someone ought to remind the kids that SCM is larger than git, regardless of what fashion dictates.
I really like the the simplicity of the plugin system. Adding (Ka)TeX support, for example, was just a matter of few clicks. Creating plugins looks straight-forward too; you can extend the site or filter / decorate text. This makes me want to use GitBook. If they don't support an idea I know I'd be able to write a plugin for it. And with time and their steady growth I probably wouldn't even have to. Sure, it's very new and has bugs, but I think this has a lot of potential.
I'm surprised there hasn't been much mention of LeanPub here; in addition to GitBook, it has what I would consider a decent modern publishing toolchain that gets out of the way for most types of writing.
I've been writing/publishing Ansible for DevOps over the past year now, and LeanPub is the ideal platform for me to both write/author the book (though I just edit Markdown in Sublime and sync through Dropbox—you can use GitHub if you'd like as well) and to publish and sell the book.
I've used GitBook a little bit, but not enough to give a really good comparison to LeanPub. But both are so much better than the old 'build your own bespoke system' or Microsoft Word-based workflow!
You ever have an idea, play it out in your head, plan it a little, build a little towards it, and just not get anywhere with it and then someone release gitbook.com? Great stuff, after Apple released ibooks author a few years ago the gears started to turn in my head about a simplified publishing platform. I guess I didn't move faster/further with the idea because it eventually just felt like a blog or website authoring tool.
Was the editor pictured on this site available to download a few months back? I feel like I played with it, or something similar.
I think the publishing/documentation/writing industries have yet to see the benefits of automation and better tooling. Writing should be simple and accessible.
What we're trying to do is automate all the painful/boring parts so that writers can focus on what they do best: writing.
I'm not surprised you had the same idea :) If you want to share your thoughts or talk, you can email me at: aaron AT gitbook DOT com
This is indeed interesting and something I thought about recently on the train. I dabble in fiction writing and was thinking about trying a kickstarter of sorts at the end of the year. One of the key things I wanted to offer was making the writing process as transparent as possible. My initial thought didn't go much beyound..."well github repo would be a start". This seems like just the thing I could use. Bookmarked and added to my Trello card for the project :)
Couldn't you technically take the output of GitBook and publish to each service (Amazon, Google Books, iTunes, etc) yourself? It seems you are only paying for the convenience of them doing it for you.
This looks really lovely - I've recently been editing / providing feedback on Gene Kim's upcoming book and we've been using a combination of O' Reilys new platform 'chimera' and a GitHub private repo - but this looks to be better suited to the process.
GitBook co-founder here. We have a lot of non-english books actually: https://www.gitbook.com/explore, over a thousand in chinese alone.
In the upcoming 2.0.0 release, we've further improved internationalisation: https://github.com/GitbookIO/gitbook/tree/master/theme/i18n We automatically detect your book's language (or you can specify itself) and so then the build chain can automatically use translations for menu entries etc ... if available in your language.
Many people use you guys not as a plural of guy, i.e. a male person, but closer to the sense of the Southern y'all, an all inclusive mode of address. Wikipedia lists is under you cognates as "Used regardless of the genders of those referred to" (http://en.wikipedia.org/wiki/You). In Britain it seems you lot has similar usage. The gender neutrality seems to be well-established in common usage, e.g. see the top answer answer to this ESE questions and the comments (http://english.stackexchange.com/questions/11816/is-guy-gend...).
We should understand that languages change, certain idioms and usages which were a bit objectionable in the past may change in meaning and vice versa. I think you guys represent the former.
In French: Vos amis sont arrivés — ils étaient en avance ("Your friends have arrived – they were early"). Here the masculine plural pronoun ils is used rather than the feminine elles, unless it is known that all the friends in question are female (in which case the noun would also change to amies and the past participle would change to arrivées).
I am always a bit surprised by the emphasis put on gender neutral language, esp. in the US, it is usually pointed that this is sexist and may lead to many of the gender imbalances. Yet other languages where this is is even more prevalent does not seem to place that much emphasis, e.g. French (http://french.stackexchange.com/questions/836/given-the-lack...). I do not speak French, my question to native speakers is: are there similar efforts in French to rid the language of sexism? According to Wikipedia L’Académie française does not quite support such movements (http://en.wikipedia.org/wiki/Gender_neutrality_in_languages_...).
It may still be advisable to avoid phrases that are easily misunderstood, even though they technically may be correct.
To put it differently, this is still dismissing quite a big share of non-native English speaking women, as you can't be sure that those subtleties are well-known in the public. (This whole sub thread demonstrates this, by the way.)
I used to feel the way you do, that “guys” is gender-neutral. However, I have encountered a large number of women who appear to be unaware that they are included when people say “you guys,” and they feel dismissed.
I could lecture them about how wrong they are, but I could also use phrases that are not subject to misunderstanding.
Things like this remind me of code. If I write something that is compiler-correct, but subject to misunderstanding, I could demand that people who find it confusing go read a few more books. Or I could write it to be read by my audience.
With code, we’ve nearly universally decided that we write to be understood, and that the audience for our code is more important than whether we are “compiler correct.”
JM2C, but that’s how I feel about the word “guys” being gender-neutral. It is dictionary-correct, but not audience-correct.
Good point, but I think you have it totally backwards: the usage in this case is audience-correct but not dictionary-correct. In fact, I think you guys is a good example where "language rules" have not caught up with usage.
An important thing to understand is that language is not governed by a strict rules, such as compilers, it's based on a social contract, in fact Wittgenstein pushed this idea to its extreme by declaring that a word's meaning is its use (this idea is not without it's own problems, of course).
I think the problem here is not that the people who object to the usage can understand the correct usage (in fact such usage is prevalent among the high-school crowd, which you can readily observe if you teach) but that they see it as sexist usage, e.g. similar to objecting to use of stewardess. I would suggest the correct approach here would give them the similar cases of y'all and you lot, not as a fry lecture but as a frank discussion.
That is probably the best argument for it, but what alternative is there for a audience-correct gender neutral guys? Do we really have to borrow yeall?
I live in Canada and in modern English spoken here 'guys' can refer to people of any gender. You often hear a group of young women (only) using phrases like "let's go guys" instead of "let's go girls". So, at least where I live 'guys' does not imply any gender.
Thank you. And may I say, gitbook is awesome. Imagine teleporting back to the 1980s and showing this to an author trying to write the next Windows 3.1 Missing Manual. They would swoon.
I wouldn't worry about it too much; look at his user name.
This service is something I could have used about two years ago, when I was still actively an author. Maybe my curiosity about the toolchain (and my love of Markdown) will pull me back in.
A “nit” is a louse egg. On its own, it is nearly invisible and unlikely to trouble you. But left alone, it hatches into a louse. You can probably survive a louse or two quite easily. But if a couple of people in a community each have a louse or two, they breed. And eventually, your community is full of lice, and then it is very difficult to get rid of them.
Monkeys groom each other regularly, picking at the nits, thus keeping them below the level where they can bloom into a full-on louse infestation.
The metaphor applies to coding style, edge cases, questionable security practices, untested code, and grammar.
Not sure why this was downvoted. Pointing out the danger of dismissing half of the population (and thus potential customers) is a perfectly valid concern.
1. A dead-simple web IDE for asciidoc with live preview[1]
2. A script for checking for common AsciiDoc mistakes (e.g. an unterminated table will mess up all text following it).
3. A script which enforces the house style.
4. A makefile which runs docker (of course) to build the book with Manning styling.
5. A buildbot configuration on my server to run 2, 3 and 4 above on `git push` and move the generated pdf and docx into a directory served by nginx.
Though it may seem like a lot, this investment has been totally worth it - the ability to push a change and be viewing the updated pdf in ~1 minute is very liberating. I can't imagine what it'd be like to not have this kind of thing in place. I can share some more of the above if there's interest.
If you're ever thinking of writing a book yourself, I'd highly recommend making the investment into a process like the above (or a tool like GitBook, though I've never tried it and it seems to be more than just a build tool) so you can get the boring stuff out of the way and focus on what you want to be doing - writing.
[0] http://docker-in-practice.github.io/ [1] https://github.com/aidanhs/AsciiDocIde