Slashdot Mirror
Tackling Open-Source Book Projects?
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?"
I understand that you want to give something back to the community that gave you linux (as do I with verious open source projects), but it seems that an "open source" book might be too easy to steal. Imagine that you truly post the source to the book (LaTeX or something), and someone latexs it and prints off a thousand copies at Kinko's, has it bound, and sells them for $10 on eBay. You'll have to use something like GPL, but does GPL really apply to books? This is pretty new area, so be very careful (if your book is pretty good, and worth real money) -- there's always some asshole that wants to make a buck at someone else's expense.
[You could say the same thing about Linux distros though. The difference is that good distros give something back. In the book example, maybe someone writes a few chapters and sells printed copies of your book with the extra chapters, but then gives you the copyright on the extra chapters. It's really hard to say...]
My other car is first.
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).
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?
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.
Take a look at CommandPrompt's book "Practical ProgreSQL" (http://www.commandprompt.com), which is published in OpenBook by O'Reilly. It is available online at CommandPrompt.
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...
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.
- 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.)
- 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.)
- 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.)
- 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.
Despite what Eric Raymond says, the vast majority of open source development is not done collaboratively. A few high profile projects like the Linux kernel and KDE do work that way, but almost everyone else works singly or in small groups. Putting some preliminary work on the web is unlikely to get you any useful help and, as you said, if anything projects that have a public roadmap before making anything useful are mostly regarded as sinkholes.
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.
Even that -- I'm sure Miguel had tons of volunteers to work on Mono but I wonder how many serious developers actually came out of it.
What I'm listening to now on Pandora...
So in addition to doing a lot of TeX and Tib work to get the bibliography part printed usably, I wrote what you will find at the other end of clbib@csli.stanford.edu with the subject "help". (I expect that it has been completely rewritten now. I certainly hope it has.) I've just tested it and it appears that it is either down, removed entirely, or no longer responds immediately..
Anyway, I never dealt with Chicago University Press directly, but I was told that they were convinced in the end that making the information available that way helped sales of the printed book.
Prime numbers are exactly what Alan Greenspan says they are -S. Minsky