I've been contacted by them before and declined because I don't want to be associated with their brand, and I've proofread a friend's book that was published through them because he didn't trust their actual editors. They do have a process that's more than just "submit anything and we'll print it", but they're not very good at what they do (books are submitted in MS Word format!?).
I think they're mostly just riding the monetary coattails of fad tech topics, they don't care if their publishings are worthless because they just print so much volume that no single book will ever be popular enough that a bad one will gain much notice, and their topics are generally so niche or topic-of-the-month oriented that there will never be enough readers for an individual book to throw much of a fit over quality problems.
Having worked on the editorial/production side in a couple of publishing ventures, being able to insist on a git-based workflow would have been a godsend. Given O'Reilly's reputation and prominence, they can get away with requiring more from their authors. If they have any high-profile authors that refuse to use git, I'm sure that they could assign an assistant to manually translate between git and the author's preferred workflow.
Not just the authors. The editors, the designers, the people who do layout, and people who just never wrote a single line of code or typed a single command into a Unix shell in their life... all of them use git, and last I heard, they all have to learn how to use the CLI version of git.
It's nuts. Git is hard enough to learn for people who know the internals of how computers work. Making people who would rather be drawing artwork learn how to use git seems really crazy to me. Hearing the coping stories from non-technical people using git is very sad.
I agree that git is an awfully complex tool for non-technical users to understand. However, the concept of version control is incredibly powerful—anyone who utilizes it has a huge advantage in productivity. Perhaps O'Reilly would be better off providing a more simplified system (perhaps even a simple GUI on top of git, offering a small subset of functionality), but I can see why they insist on a VCS-based workflow.
They have some nice tools now that work through git, although you never have to actually interact with git at any point during the writing process, unless you want to. Git just runs on the back end.
Comments
They're the print equivalent of shovelware.
I've been contacted by them before and declined because I don't want to be associated with their brand, and I've proofread a friend's book that was published through them because he didn't trust their actual editors. They do have a process that's more than just "submit anything and we'll print it", but they're not very good at what they do (books are submitted in MS Word format!?).
I think they're mostly just riding the monetary coattails of fad tech topics, they don't care if their publishings are worthless because they just print so much volume that no single book will ever be popular enough that a bad one will gain much notice, and their topics are generally so niche or topic-of-the-month oriented that there will never be enough readers for an individual book to throw much of a fit over quality problems.
Other than O'Reilly, I think most publishers still insist on MSWord for submissions.
The times I've worked with them, No Starch was quite happy with LibreOffice, if that's any better.
O'Reilly's insistence on making everyone use git (including non-programmers) seems a bit nuts to me.
Having worked on the editorial/production side in a couple of publishing ventures, being able to insist on a git-based workflow would have been a godsend. Given O'Reilly's reputation and prominence, they can get away with requiring more from their authors. If they have any high-profile authors that refuse to use git, I'm sure that they could assign an assistant to manually translate between git and the author's preferred workflow.
Not just the authors. The editors, the designers, the people who do layout, and people who just never wrote a single line of code or typed a single command into a Unix shell in their life... all of them use git, and last I heard, they all have to learn how to use the CLI version of git.
It's nuts. Git is hard enough to learn for people who know the internals of how computers work. Making people who would rather be drawing artwork learn how to use git seems really crazy to me. Hearing the coping stories from non-technical people using git is very sad.
Git with a Gui (Sourcetree, Github etc.) is a pretty straight forward exercise.
I've seen designers use version control with things like: filename.FINALE.jpg filename.Last Finale.jpg filename.Approved Finale.jpg etc.
Certainly its worth the half hour getting your head around the basics of SourceTree than that...
I don't know anything about the situation myself, but jordigh (https://news.ycombinator.com/item?id=9694685) said:
(emphasis mine).
I agree that git is an awfully complex tool for non-technical users to understand. However, the concept of version control is incredibly powerful—anyone who utilizes it has a huge advantage in productivity. Perhaps O'Reilly would be better off providing a more simplified system (perhaps even a simple GUI on top of git, offering a small subset of functionality), but I can see why they insist on a VCS-based workflow.
They have some nice tools now that work through git, although you never have to actually interact with git at any point during the writing process, unless you want to. Git just runs on the back end.
I guess things have improved. The stories I heard were about a contract-based indexer having to use CLI git.