Comment My Experience Writing OS Books (Score 1) 135
Hi, my name is Carey Bunks, and I have written two OS books: Grokking the Gimp and The Lasso: A Rational Guide to Trick Roping.
Here are my two cents on writing books, and on the theory that community participation benefits a book in the same way it benefits code (correcting errors, keeping it up to date, etc). I suspect that this theory is wrong except for some special cases (for example, dictionaries). However, I can warmly recommend the idea of making a book open.
I claim that writing a good book is very different than writing good code. Generally, good code should be well organized, carefully designed, with its components being as modular and as independent as possible. If successful, the result should be an application that evolves more gracefully, and is more easily updated and maintained by multiple developers.
A good book should be well organized, however, does not, indeed must not be modular. Why? Because a human mind does not understand nor process the words in a book the way a computer does a program. Humans like good organization. However, the brain also needs association of ideas and redundancy. We humans like to see the connections between things, and we need to be constantly reminded.
So, although a table of contents may be very organized, a good book contains chapters that are hardly modular. Good chapters should be rich with references to other parts of the book, showing how the ideas presented in different parts work together. Furthermore, chapters will often contain redundant recaps of other chapters, again showing how the pieces fit together. When there is enough of this type of self-referencing, it creates a synergy that helps readers better understand and better appreciate the material.
My conclusion is that a book is more like a cathedral than a bazaar. It requires a master architect who conceives the original design, and then literally weaves the many threads together into a single whole. The very nature of the work resists participation or subsequent updating by third parties. Thus, trying to update chapters is likely to make a book incoherent as the relevancy of references and the synergy of ideas start to break down.
Second, my theory on writing a good book is coherent with the above discussion. I believe that the most important process in writing a good book is re-reading and re-writing. It's kind of like refactoring of code, except instead of making the resulting book more modular, it makes it more connected. As the book starts to take form (near the end of the first draft), it is important to intensely review what has been written. This will give rise to all sorts of small scale revisions -- spelling, grammar, and sentence construction corrections. However, it also allows the author to revisit the overall connectedness of the work. Does the story hold together? Is it coherent? Does it provide insight into the underlying concepts presented by the book? This is the most valuable part of the revision process.
Finally, let's face the facts. The way the publishing industry works, it is very difficult to make any money writing. There are some counter-examples to this, however, the overwhelming majority of books make less than $10k for their authors. Compared to the 6 to 9 months of full-time work needed to produce a quality book, you are better off not trying to write for a living. Thus, it is unlikely that deciding to make a book open will ruin its economic potential. However, in some cases, I think that making a book OS can help improve its market share (see my thoughts on this in this interview on LWN). On the other hand, creating a book is a very rewarding personal experience, and can definitely improve ones professional profile.
Here are my two cents on writing books, and on the theory that community participation benefits a book in the same way it benefits code (correcting errors, keeping it up to date, etc). I suspect that this theory is wrong except for some special cases (for example, dictionaries). However, I can warmly recommend the idea of making a book open.
I claim that writing a good book is very different than writing good code. Generally, good code should be well organized, carefully designed, with its components being as modular and as independent as possible. If successful, the result should be an application that evolves more gracefully, and is more easily updated and maintained by multiple developers.
A good book should be well organized, however, does not, indeed must not be modular. Why? Because a human mind does not understand nor process the words in a book the way a computer does a program. Humans like good organization. However, the brain also needs association of ideas and redundancy. We humans like to see the connections between things, and we need to be constantly reminded.
So, although a table of contents may be very organized, a good book contains chapters that are hardly modular. Good chapters should be rich with references to other parts of the book, showing how the ideas presented in different parts work together. Furthermore, chapters will often contain redundant recaps of other chapters, again showing how the pieces fit together. When there is enough of this type of self-referencing, it creates a synergy that helps readers better understand and better appreciate the material.
My conclusion is that a book is more like a cathedral than a bazaar. It requires a master architect who conceives the original design, and then literally weaves the many threads together into a single whole. The very nature of the work resists participation or subsequent updating by third parties. Thus, trying to update chapters is likely to make a book incoherent as the relevancy of references and the synergy of ideas start to break down.
Second, my theory on writing a good book is coherent with the above discussion. I believe that the most important process in writing a good book is re-reading and re-writing. It's kind of like refactoring of code, except instead of making the resulting book more modular, it makes it more connected. As the book starts to take form (near the end of the first draft), it is important to intensely review what has been written. This will give rise to all sorts of small scale revisions -- spelling, grammar, and sentence construction corrections. However, it also allows the author to revisit the overall connectedness of the work. Does the story hold together? Is it coherent? Does it provide insight into the underlying concepts presented by the book? This is the most valuable part of the revision process.
Finally, let's face the facts. The way the publishing industry works, it is very difficult to make any money writing. There are some counter-examples to this, however, the overwhelming majority of books make less than $10k for their authors. Compared to the 6 to 9 months of full-time work needed to produce a quality book, you are better off not trying to write for a living. Thus, it is unlikely that deciding to make a book open will ruin its economic potential. However, in some cases, I think that making a book OS can help improve its market share (see my thoughts on this in this interview on LWN). On the other hand, creating a book is a very rewarding personal experience, and can definitely improve ones professional profile.
