Open-ended Publishing; Fractals

Back in November, O’Reilly had this article about Open-Ended Publishing on their website. I love the concepts of fluidity in publishing, and I love the fluidity in the writing process that Scrivener makes possible.

Writing is sometimes about constantly referring to one reference or multiple references. Sometimes it’s about managing a continuity between ideas or a storyline. It’s shaking down, flagging, organizing, and commenting. At other times, it’s about having a blank screen in front of you and simply writing. One is rather amazed (and relieved) to find that someone has already recognized the fractal structure of writing and has created a tool that can shift gears so smoothly.

Thanks! Thanks for the link to the interesting article, too.
Happy New Year,
Keith

Yes, good article! One of my favourite tech publishers is The Pragmatic Bookshelf (an imprint of The Pragmatic Programmers). They put out consistently good books (and if you are a Ruby programmer, they also put out the best books in the industry on Ruby), and their purchase plan is modern and perfect for technical manuals. You buy a PDF (with the option to get a hard copy shipped as well), and from that point onward you have access to that PDF from their server. If it gets revisions from the author(s), you’ll get a notice updating you to the fact that a new copy is ready to download. For books in progress, you can buy it early and get access to the “beta” versions of the book as it is written. O’Reilly has, of course, also been a leader in this form of publishing, but I’m less experienced with their online system, Safari. I tend to pick a few books that I need, rather than benefit from a subscription model where I have access to a massive library and get a steady flow of “tokens” to download full copies. The public library does quite well for me on that score, as my demands are more simple than what O’Reilly is targeting. I’m just not that deep into the IT scene to really need a constant new flow of books.

I skimmed the article so this might have been addressed, but one area I would disagree with the writer on is the notion that editions have no place. I think in technical matters they do. A book about Ruby 1.8 is going to have a lot of difference with a book about 1.9, and trying to write a book that encompasses both would read like a legal document. When the target of the document is itself a fluid and rapidly changing piece of information, and one that often becomes “bound” at older levels of fluidity due to adoption rates, stability, and so forth, it is important to have documentation that is tied at the version level, and I think editions are good for that. If your corporate server is using an older version of Perl, it’s good to know your documentation targets that version. It makes sense to reuse the concept of an “edition” for this.