Slashdot Mirror

← Back to Stories (view on slashdot.org)

Tackling Open-Source Book Projects?

Posted by Cliff on from the taking-a-book-by-its-horns dept.

Wheeler asks: "I am currently writing a book ('The Directory Services Cookbook', shameless self-plug), which I plan to publish under some form of open license, once it's finished. At this point I am really looking for clues on which license would be appropriate for your classic, not-necessary-digital work of creation. And while we're at it: Can other OS book projects share experience on how to tackle the process of writing in general. I personally think a little Linus T. should be in every project doing editing, checking for style and layout, the works. Any comments?"

5 of 135 comments (clear)

  1. Philip and Alex's Guide to Web Publishing by lesinator · · Score: 4, Interesting

    I suggest checking out Philip and Alex's Guide to Web Publishing. It is available in both online and print versions (in addition to being a fantastic read).

  2. Clearinghouse for editorial contributors by EisPick · · Score: 5, Interesting

    My technology skills are too soft to contribute as a developer to an open-source project, but I'm an experienced editor who'd love to have the opportunity to copy edit for a project or two.

    I wouldn't know where to start to find a match for my time and skills. Are there resources that list projects like the one above looking for editorial assistance? If not, should there be one?

  3. Definitely use cvs by AugstWest · · Score: 3, Interesting

    I would separate each chapter to be checked out as a whole from CVS.

    Version control is indispensible for stuff like this, yet people rarely think to use it.

  4. Linux Cookbook is a real "Free" book by Anonymous Coward · · Score: 3, Interesting

    dsl.org has Linux Cookbook which is an open source book that seems to be doing really well as a "real" book. The real sources used to write the book and publish it are put up on the web for free...

  5. Re:Open Book approach by Jerf · · Score: 4, Interesting
    One thing that kind of gets me scatching my head (I'm sure its my intellectual shortcomings, not those who initate these projects) is the idea that "I'll finish this then release it as open source".

    I've been considering doing this very thing. Here's what I've come up with. Most of these apply equally well to books and programming projects.

    1. Vision: If you have a specific vision driving the creation, it may be easier to finish the project (to at least a first approximation) then to try to convey that vision to a loosely-knit bunch of developers/writers who may or may not care about or even understand your vision. Once you have code/copy, people can judge whether they like the direction of a project, rather then attempting to steer it early on into what they want. (Team management is not free.)
    2. Reputation: I know I don't have to release The World's Most Beautiful Code/Book to impress people... but open source or not, crap is crap, and most, if not all, early drafts/programs are crap, unless VERY carefully designed from the get-go. (Not something Open Source as a whole is famous for; design tends to be either the exception, or something you consider at version 3. This is not all bad, but one might not want to put one's name on what is essentially pre-alpha code.)
    3. Attacting others: Related to but distinct from reputation, early crap code will probably not attract any one to work on your code/book. (Remember, there's no magic to Open Source; the destiny of your average FreshMeat.net project is probably to attract not a single developer who will stick around in even the medium term.)
    4. Commitment: By putting my project out in the open, it implies a certain level of commitment to it, even if that commitment is replying to numerous emails with "I totally refuse to support that program/correct the book at this time." The "Open Source" culture supports the idea of dumping code into the world in theory, but in fact you can't completely dump something content onto the world without some measure of responsibility for it. I like the fact that if I abandon my project for any reason, NOBODY will give me flack for it; nobody even knows it exists, and that's liberating.
    For my project (estimated odds of EVER being released publically: 10%), "Vision" is my primary reason. I don't want to explain myself any more then I have to. Peer review is likely as not to be crap, both because it's unlikely I'd attract the 'good' reviewers (since they are on bigger name projects), and the reviewers are unlikely to understand where I'm going. I'd only ruffle potential contributors feathers when I tell them that their nifty-snazzy idea completely fails to fit within my framework, and I'm quite uninterested in it. (No matter how you candy coat that, people will still take it quite badly.)

    Personally, I'd recommend having some sort of functional product before releasing anything as open source. The exception (which totally doesn't apply to me!) is if you have a big enough name or big enough project to put something together on the strength of that alone. Imagine one of the big KDE/GNOME developers starting a new component system from scratch, in public. It works; they get all kinds of developers willing to work with them before even a single line of code is written. Now imagine me, "Jerf from Slashdot", making the same (kind of) announcement. The silence is deafening.