Three years ago, when I pitched the Open Content idea to Macmillan for the ill-fated KernelBook there was a lot of noise that ended up with the "Open Publishing License" that is not quite the same as a free license; I was pretty much snubbed by everyone that I needed involved to make the project work. Tim Waugh was on my side, even contributed a chapter, but the only others I could get were outside of the kernel project, and the kernel project people couldn't even give us a few minutes here and there to do a bit of Wiki-ness. I got a raft of excuses, but the top one was no one wanted any part of any book that wasn't either ORA or 100% free.

But that's all water under the bridge now, and I see today that the book we were building was apparently way ahead of its time because now I hear that, given the endorsement of in-crowd celebrity Bruce Perens, the same deal will even make the NYTimes (Steal This Book? A Publisher Is Making It Easy) with the 'revolutionary concept' that Prentice Hall is going Open Publishing. Guess the Kernelbook was just born too soon.

Licenses aside, though, regardless how you treat the content that gets written, I did discover something else vitally important during the Kernelbook experiment, something Bruce and this NYTimes article do not yet cover: Before technical trade books can really do the job of describing the subject matter before it goes obsolete, it's not enough to be open content, the manuscripts must also be collaborative written in a continuous just-in-time publishing model. Forget which printing or which edition, the book shipped to the stores today should be different from the volume that goes out in the next batch; trade books should be printed only as needed, on demand ... just like the way Sun publishes their manuals, fresh out of the CVS.

Here again, we were way ahead of the other trade publisher peers even though we were only doing what projects like PHP had been doing for years. But our method of collaborative revision-controlled writing of the KernelBook via DocBook and CVS had an unforseen and fatal process flaw ...

I had the publisher at Macmillan on my side, several tech editors, and the printing plant which is already XML based was eager for the day when what they printed would be fresh from the author's pen, but in the final straw it was the proof-readers and copy editors who just could not move beyond their MsWord-based font-painters, and that meant the pure-XML play was thwarted by the middle-ground.

Our project wasn't without success. We managed to break the ground at Pearson through their MCP arm, other books followed with OpenPublishing licensing and today manuscripts are allowed in any format, even ASCII; some of the staff are acquainted with HotMetaL and ArborText, but that's as far as it goes, everything eventually gets channelled into the word-garberator and the author will still get their manuscript back with orders to painfully insert the absurd CO/CC/BE MsWord macro-flag codes (you had to learn dozens of these) that successfully turn otherwise logical and orderly DocBook into a kind of garbage that no-one can properly edit.

Anyway -- back to the future and pleasant-er subjects like that, I still believe tech publishing will unavoidably anneal to JIT publishing down a continuous-revision pipeline. During the course of the Kernelbook, I wrote several plans for end-to-end XML-based publishing where the manuscript does not really exist, where it's a collection of sections and variations, indexed, threaded and exported for books. RedHat Unleashed needn't be a completely seperate project from Linux Unleashed, just a variant filtering of the book nodes, just as the French or Chinese editions are filterings for the alternate language nodes, and all of it online updated on the fly by the community who uses it. The art of the author/editor would be one of filtering, pulling what they need from the knowledge base to create other titles as well, semantically linking it all through topic-maps ...

Wait a minute. I've just described the community book feature of Drupal! Ok, not quite, but Drupal is moving in that general direction, and if only they'd export something more semantically useful than XHTML and perhaps fold in the Lampada document archive browser project over at The Linux Documentation Project...