Hacker News Reader

Comment by jordigh | Hacker News Reader

I'm generally unimpressed with Packt. Bill Pollock said (so consider the source) that Packt is not really a publisher, but just a printer. They don't really have any (copy)editors. They make everyone else do the work and pay them with complimentary copies of their (in my opinion) low-quality books.

View on HN

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.

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.

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...

> Git with a Gui (Sourcetree, Github etc.) is a pretty straight forward exercise.

I don't know anything about the situation myself, but jordigh (https://news.ycombinator.com/item?id=9694685) said:

> last I heard, they all have to learn how to use the CLI version of git

(emphasis mine).

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.

I almost became an author (of a video series) for them. I signed a contract and produced a couple of chapters. I found they had pretty reasonable copy editors, at least the one I worked with was helpful and thorough.

My main problem, and the reason I didn't finish the series was their advance was very low and the royalty rate was too. After looking round it seemed the rate was probably reasonable for authors in other fields, but very bad compared to what I would earn actually programming. Plus they absolutely refused to give me any indication of how many sales I could expect. I couldn't justify spending the time to complete the series vs regular contracting. I think this low remuneration affects the quality of the authors they are able to attract, so you're right in that part.

The advance they offered me was less than a quarter of the advance I've seen quoted for other specialised tech books, and about a tenth of what an author would expect for a best-selling mainstream consumer-oriented title.

They also spam people on mailing lists looking for authors. (Not spam the mailing lists - harvest addresses and contact people more or less at random.)

>I think this low remuneration affects the quality of the authors they are able to attract, so you're right in that part.

From what I've seen, not all the books are terrible. ;)

But they're certainly not in the same league as No Starch, or most of the self-pubbed titles on LeanPub.

I wrote a book for Packt and made less than $1000 from it, two years later. However, it is something to put on your resume (if you want to) and I managed to use it to leverage a book deal for a more reputable publisher later on. So it can be useful if you think you might want to write books in the future. However, yeah, the money isn't going to be worth your time by a long shot.

I did a video for them, and got a book deal with another publisher off the back of it.

I actually learned a lot through doing the video, and the guidance I got was pretty good over the technical aspects of putting a video together. The later script editing and review stage was dismal, though. I got the feeling the less experienced editors I worked with later were overworked.

Reply on news.ycombinator.com