4 ms·
Your post suggests a lack of critical thinking on your part. 1. I sell my book to a used book store. 2. You buy the book I sold to the book store. 3. Somehow
by iamjustlooking 16y ago
Your post suggests a lack of critical thinking on your part.
1. I sell my book to a used book store.
2. You buy the book I sold to the book store.
3. Somehow the author also takes a cut in that sale?
- nkurz 16y agoThat was my initial thought as well, but reflecting more it's a decent question. On the surface, would you expect that a network exists for university libraries to pay for articles included in student class packets? Would you expect that the venue is expected to pay when a cover band plays in a bar? That musicians theoretically get paid when their song is played on the radio or streamed on the net? There's a lot of 'magic' happening, and it wouldn't be that much of a stretch for libraries or used book stores to participate. For all I know, there's even a country somewhere that already does it.
- julius_geezer 16y agoRobertson Davies once discovered that his local library had collected more in fines than he had collected in royalties on one of his books. He started a campaign to pass laws for libraries to pay something back to the authors; I assume it went nowhere.
- rmk 16y agoI have always wondered whether technical books are lucrative for the author. Obviously, a buyer of a book helps the author get a royalty. So that includes library purchases as well... But, if that is the only source of revenue for the author, writing a book would be a thankless task (as far as tech books are concerned, not mega-blockbusters like the DaVinci code that can earn great revenue via book sales and also the movie optioning). So why would a person write a technical book if the financial return is not good?
- tonystubblebine 16y agoI've worked for a publisher of technical books and written a small technical book. They are very very rarely lucrative for the author. However, they almost always bring a lot of clout and usually involve learning a subject at a deeper level than you normally would. So, usually it's worthwhile to write at least one if you have the opportunity. There are a couple of things to keep in mind: 1. Books often challenge an author's discipline and then become extremely painful exercises. With most programming you get regular feedback. Many authors go months without getting any feedback at all. So, be aware, time management is important. 2. In my opinion, longevity of the information you're writing about matters more than anything. The primary benefit of writing a technical book is getting to claim to be an expert for awhile (that and helping people). If you were to write a Javascript book in the O'Reilly cookbook style (how to find the length of an array, etc.) you could expect to be a javascript expert for many years. If you were to write an Android Application Development book, you might only have a year. I published my book (a pocket reference for O'Reilly) in 2003 and landed my biggest client this year because the technical decision maker had a copy on his desk. That's why I'm a believer in evergreen topics. 3. Lucrative means $50-100k. I have a friend who tells a story about how the car he drives came from his first royalty check, $42k. That's a lot, right? Maybe he made $100k on that book for three months of work. But it's not repeatable. The way that it became lucrative for him is that he parlayed that into high dollar consulting and eventually CTO of a well funded database startup. If you're savvy about picking a topic with some interest, you should expect to make $10-20k lifetime. That's less than you'd make in salary. 4. Get co-authors. I think that's the most efficient way to write a book. That way you're not responsible for the entire thing.
- deleted 16y ago[deleted]