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?"
Many people create valuable content and then insist on hosting or publishing the content themselves.
Instead consider contributing your content to a public content repository like Wikipedia.
This allows other people to easily contribute to and update your work, even if you lose interest or something happens to you. Additionally, your work will be redundantly stored and likely accessible for the far future.
Do whay O'Reilly does with their Open Book program.
"Don't blame me, I voted for Kodos!"
Bruce Eckel publishes books (like "Thinking in Java") as both a free online book, yet sells the printed copy. What he does is publishes the book like normal, but also makes them available for free on his webpage. So if you ever need it to reference, you can jump online to read it. And to support him, most people buy a copy of his book. Its the best of both worlds.
Another nice advantage is he has books that he isn't finished with available online ("Thinking in Patterns" is one of his), where people can read it and give him feedback before he takes it to the press... Check grammar, find things that are easier to reword, play around with his example code, etc... Its almost like an open source project right there. And he makes money on his books (cause, any java coder that has read "Thinking in Java" owns a copy. Its like a Bible for Java).
This may be a technique you may consider...
Good quote, too many chars. Seriously, the slashdot 120 char limit sucks!
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).
There's a difference between two. Open-source means anyone can take your source code (in LaTeX or something like that), make some changes and produce his own version of the book. I have some doubts about this model, though. Most ot the free books I've seen are just free. Anyone can use them but not contribute.
If you really want to produce a "collaborative" book, take a look at the Wiki model.
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?
My own book (The Instructional Use of Learning Objects) is available online for free (under the OPL) as well as in costs-money print form. Not only does this give you the opportunity to have people submit live errata, etc., but the electronic version of the book is the best press the print version could get. We pre-sold around 500 copies before the book was even to the printer by having the material online.
The other great opportunity afforded by having the book online is the community / discussion you can facilitate if you can convince your publisher to put the URL to the free online version on the cover of your printed book (this was not so easy for me).
John Seely Brown and Paul Duguid took a similar approach with The Social Life of Information.
I don't really understand the problem. As you point out, somebody could do the same with a Linux distro, or any other piece of OSS. Generally, customers won't be stupid enough to shell out much dough for a product that they could obtain for no cost, unless they feel that they're getting something for what they're spending (like the printing and binding.)
The danger would come from somebody attempting to claim a new copyright on your work (fairly easy to deal with, if you register your work), or somebody modifying and redistributing it as their own work. In either situation, you've got a decent court case. I don't know how strong OSS licenses may be in the print arena, but if you did have to go to court, I think you'd have at least an even shot. Hopefully, nobody would be stupid enough to test you.
The author could always keep an eye out for somebody trying to do this, and potentially undercut him/her by selling copies for a lower price.
So far, this is somewhat like what Bruce Eckel is doing. First, you give something back to the community, but you still can make some money, without having your work stolen.
But, add the following clauses to your copyright:
Just my $0.02.
Do you want to just give the book away for anyone to do anything with? Then just release the book into the public domain.
Do you want to allow free redistribution, but restrict people from making any changes? Then say that in your license.
Do you want to allow changes, but want the changes to be clearly attributed to the new authors? Then say that.
These things aren't rocket science. Just say what you want to happen with your book in clear straitforward language and that is how it will be.
-- Never make a general statement.
You have to be careful when dealing with many paper book publishers when discussing publishing something developed from the Internet. This territory is unfamiliar, and will often lead to dire consequences if all parties involved don't understand what's going on. Take the case of Eric Weisstein, author of the CRC Concise Encyclopedia of Mathematics. His book was based off of years of his own work on his website, Eric Weisstein's World of Mathematics, and some collaboration from outside sources. After CRC published the book, they demanded that the website be taken down, effectively ending all collaborative work on the project. You can read more about the incident here. One calendar year and lots of litigation later, the website is back online. Don't let this happen to you.
Free messageboards and more! Your girlfriend's seen myWang
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.