I don't think the book will in any way have any monetary payback for the authors. I was thinking about putting it up on Lulu for people to buy with a nominal royalties per printed book purchase (e.g. $5-10), with the proceeds for that going either to Apache, or if possible to Tapestry.
I think that trying to account for everyone's contribution and being able to fairly distribute any benefits from the sale of the book will just bee too much work and a demotivator for the general community to contribute. I asked Jared Richardson (the author of "Ship It") for an opinion on the subject of writing the book, here's a brief quote: --------------------- I'm also very interested in the technical side of such a collaboration : do you typically use word, do you use some kind of version control, what format you write the book in (e.g. docbook, wiki, whatever). The Pragmatic Programmers have an XML-esque language for book writing and it's stored in Subversion... *it was nice to be able to diff. It was also nice to be able to generate the "finished" looking book*. I can't tell you how much of an encouragement it was to see it in a press ready format. Can you advise me on any pitfalls that I should watch out for ? Really, any part of your book writing experience would be very useful.. It will take much longer than you think. Everyone's writing will stink at first. It takes many passes and rewrites to get your writing style acceptable. But the bright side is that you'll write better for the rest of your life. Are you planning on releasing it open source or selling it? Either way, be very clear about what reward a contributor would receive. If I were you, I'd come up with something for people to criticize. Start with an outline of what you think the book should cover. Then start contributing in sections and samples. What's the goal of the book? An intro to Tapestry? Advanced user guide? Reference? It's easier to stay the course if everyone understands the goals and agrees with them. ------------ Cheers, Alex Kotchnev On Wed, Aug 27, 2008 at 4:48 AM, Hugo Palma <[EMAIL PROTECTED]> wrote: > I also agree with the DocBook format. > > A have question thought, if the plan is to publish the book in a printed > paid version there's obviously going to be income from this effort. How will > that work being the book a result of community effort ? Where will the money > go to ? > > > Alex Kotchnev wrote: > >> I myself lean a little bit towards using DocBook for such an effort. Here >> are a couple of reasons I think it might be the right tool for the job: >> >> 1. As it was mentioned before, the multiple formats export option is >> extremely useful, as generally, I want to write content, and not >> necessarily >> spend time on formatting things. There certainly may come a time when we >> might need to spend time on formatting the whole book uniformly, but at >> least initially, I'd rather not worry too much about that. In my opinion, >> although the "semantic xhtml markup" seems like an easy way to start with, >> it wouldn't be as expressive and explicit as docbook about the elements in >> the content of the book (unless someone is willing to spend time to >> heavily >> customize CSS stylesheets, write utilities to parse this "custom" format, >> etc) >> >> 2. A couple of years ago, I used DocBook to draft the first couple of >> drafts >> of my thesis, and it worked fairly well. Later on, when things heated up, >> I >> was able to import this first draft into OpenOffice and do some of the >> fancier stuff with it (e.g. I was adding index terms which is also >> possible >> to do w/ docbook, but I was under time pressure) >> >> 3. Although there will be some things to learn in starting w/ DocBook, >> there >> are a couple of mitigating factors: >> * There is the "Simplified Docbook" ( >> http://www.docbook.org/schemas/simplified) which makes the learning curve >> a >> lot less steep. If we decide to get fancy later on, it can certainly be >> revised. >> * There are a number of GUI tools for editing DocBook and not even know >> what's under the covers : e.g. XMLMind ( >> http://www.xmlmind.com/xmleditor/) >> is free for personal use. >> * A number of XML editors support DocBook out of the box : jEdit has xml >> completion based on the DTD, NetBeans has a DocBook module (thanks to >> Geertjan and his crew), I'm sure that Eclipse has something there as well. >> * (although I'm very suspicious of php apps) This docbook project that >> Hugo >> mentioned (http://doc-book.sourceforge.net/homepage/) that allows >> wiki-like >> editing of docbook books and chapters might be worth taking a look at to >> support "simplified" editing interface for a more distributed crowd. >> >> 4. Although this is a pie in the sky goal, if we somehow manage to round >> up >> a publisher (e.g. something other than Lulu.com) who might want to print >> the >> book for real (wishful thinking), I was under the impression that some >> publishers (e.g. OReilly) do support DocBook as an input format >> >> 5. I don't think it is just a matter of being able to export to PDF. My >> point is that for example, other tools (e.g. Confluence, XWiki, etc) >> supports exporting to PDF from it's pages, but other than the tool in >> question, nothing else could do the same. With DocBook there is a wide >> array >> of utilities (both open source and commercial) that can manipulate the raw >> docbook in a variety of useful ways. >> >> I am in the process of badgering all my contacts for advice on best >> practices on how to proceed with writing a distributed type of book. >> Geertjan responded to my question about writing a book on his blog ( >> http://blogs.sun.com/geertjan/entry/collaborative_writing_in_a_distributed >> ) >> , and overall his suggestion is that writing a book with other developers >> should be run just like any other software development project (in terms >> of >> infrastructure - e.g. source control, tooling, etc). I've also sent >> inquiries to a couple of other people I know, who might be able to provide >> some advice on the subject, we'll see what comes out of that. >> >> I also trolled the web for some references on the subject, and here are a >> couple of interesting experiences on the subject (so, that's what Howard >> was >> referring to when he was saying that writing book involves a lot of dull >> work): >> >> http://www.xaprb.com/blog/2008/06/15/what-is-it-like-to-write-a-technical-book/ >> http://www.emergentchaos.com/archives/cat_writing_a_book.html >> >> Anyway, I guess my point in posting these two links are they give an idea >> of >> what it is to publish a book w/ a real publisher. I don't think that >> anyone >> thought pulling off a book would be easy, but my (naive) hope is that >> being >> able to spread stuff among a larger number of people will make it less of >> a >> drag (although it would remain a huge amount of work) and more fun (by >> collaborating w/ everyone else). From the articles above, I especially >> liked >> the advice of writing progressively more detailed outlines (far beyond the >> urge of starting to write sentences). I also liked some of the heuristics >> for better style. >> >> Cheers, >> >> Alex Kotchnev >> >> >> >> On Tue, Aug 26, 2008 at 3:18 PM, Carl Crowder <[EMAIL PROTECTED] >> >wrote: >> >> >> >>> I'd be keen to help out, whatever the format used to write it. >>> >>> I assume there would be an editor to order it once it's written? >>> >>> --------------------------------------------------------------------- >>> To unsubscribe, e-mail: [EMAIL PROTECTED] >>> For additional commands, e-mail: [EMAIL PROTECTED] >>> >>> >>> >>> >> >> >> >
