Slashdot Mirror
Funding Linux TCP/IP Stack Documentation Project?
"Doing the update as a Second Edition (even if Coriolis was on board) means that useful information wouldn't be available until sometime in 2001 -- at which time the information will be obsolete again. Based on reader feedback, that simply isn't acceptable. The format of the First Edition is incredibly hostile to incremental publication. So Heather and I have decided to start over, completely re-designing and re-writing the book from scratch, incorporate additional information that was beyond the scope of the original book, and publish it incrementally on the Web. We have figured out the mechanics: we have a rough page design, we have a start on the publishing automation tools, and we have a Web server.
Based on some suggestions (one from a /. reader) here are the options as we see them for funding this project:
-
Subscriptions: Our original idea (mentioned in our page) was to sell subscriptions to access most of the material; some material would be open to show what we do. Buyers of our book would get a discount on their first subscription, based on the fact they had bought our book. To keep overhead down, we were expecting to sell subscriptions on a quarterly and annual basis. We thought that $12/year or $4/quarter would strike a good balance. (We would also investigate how to accept subscriptions in currency other that U.S. dollars.)
-
Advertising: The old standby, banner ads, is the most distasteful option, but one that we have to consider. I've noticed that a number of Linux sites use banner ads to help fund the effort. In our page design, we want to maximize the use of Web page real estate to show code and commentary, not ads. There are a couple of issues, such as where to place the ads, that would need to be addressed, but given the page design we would incorporate the ads in the commentary, and not the code or control panes.
-
Contributions: Grants and subsidies from interested parties would help the project; if the contributions were large enough we could abandon both advertising and subscription completely and make the site open to all. We would use the Seti@Home treatment of contributions as a model, so that everyone who contributes can be recognized. Where would we put out our tin cup?
-
The Eudora Model: One mixture that might work is to mimic the model used by Qualcomm's Eudora MUA for Windows and Macintosh: display ads to those who want to use the "free" service and suppress ads for those who subscribe. This adds a little complexity (and an annoyance to the free users) but it means the information would be available to all.
I'm sure these aren't the only way to do the trick that keeps us off the street. I welcome comments, suggestions, and brick-bats from Slashdotters.
Why not 'open source' the book as well? Part of the reason Heather and I didn't try to farm out the code analysis is that we wanted to have a consistent style. Frankly, it would be as much work to accept contributions and then edit them for style and structure as it would be to do the entire job ourselves. In one sense, the book will be open source in that readers will be able to post "yellow stickies" on our commentary...and readers can see the yellow-stickies (with attribution)."
For instance the quality of many online magazines is dropping sharply because of it.
/., etc) do so well. They provide little valuable content of their own, but turn existing content into information. This is actually more valuable in an online world than trying to produce good content.
There is no shortage of content online. In fact there is rather too much of it. Some of it good, much bad, but it is out there. (From the point of view of the person who is trying to make money providing it that is. Clearly not from the point of the view who wants content that does not yet exist.)
However until content appears in a digestable form, it is not information. Which is why sites which provide some sort of searching and indexing of content (search engines,
Which sucks if you want to produce some content of your own.
Cheers,
Ben
My usual seat in the cluetrain is at A HREF="http://pub4.ezboard.com/biwethey.ht
W. Richard Stevens wrote one of the definitive books on TCP/IP, and it was one of my primary reference materials when writing IP Stacks Commentary...it's one of the reasons that that Heather and I dedicated the book to his memory, and to the memory of Jon Postel, the first document guy. If I had the resources that Stevens had, I might try to aspire to write a book to that level of quality.
I won't apologize for the limits we worked under. They were the parameters, and we lived with them. That's one reason we are thinking about dumping paper completely--the format just doesn't work in the Open Source environment.
Can we do better? Yes. Will we do better? Only time will tell. You will be the judge, dear reader.
All good points, but when I'm doing something for which I need more than a glance at the documentation, there is nothing that beats having a good book on your desk. I can see how good a book of mine is by merely looking at it... The more it is thumbed through, the more post-it notes sticking out: all omens of its qualities...
The information in the book is not obsolote (2.4 TCP/IP Stack - not 2.0.34, that was the first edition!), and I can imagine that having a book on that topic would really be interesting.
Perhaps it's me, but for more than a couple of screenfuls, I prefer something on paper.
Okay... I'll do the stupid things first, then you shy people follow.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
Puh-leeze don't whine that they don't give their work out for free: they are writers, they write for a living. If you have a problem with this: fine, go somewhere else. There are a number of people who are working on Free Software/Open Source while being paid for that, and someone writing documentation shouldn't be treated any different.
If they think they can sell a good-written book about Linux TCP/IP internals, it's their choice to try just that. And you and me and everybody else can choose if they would like to pay for that. Some of us will, others won't. But you should really cut the 'do it for the love of it'-crap.
Okay... I'll do the stupid things first, then you shy people follow.
Okay... I'll do the stupid things first, then you shy people follow.
[Zappa]
...is people who can read a clearly written paragraph and reason about it logically.
I didn't say they "should give their work out for free". I'm saying that if they want to write something, I'm not obligated to pay for it. In other words, if they want to write a book, they can feel free to do so. If I want to give them money for it, I should feel free to do so. But having them come to Slashdot asking for money up front to fulfill a need that they see is not appropriate. Imagine if Linus had gone to some BBSs in 1990 asking for money to develop a replacement Unix kernel. Ridiculous. He just went ahead and did it, expecting no payment (indeed, expecting no fame or even assistance).
--
Bid on me!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Books 24x7 has a subscription model for a great deal of technical literature on their site on many a subject. Perhaps you could persuade your publisher to pursue a deal with them .
--
You mention that one of the largest complaints about Linux is that there is a lack of high-profile documentation. Well, I think you have to differentiate here: He/she who is really after the innards of the revamped IP stack will devour anything that is close to a documentation such as source comments, HOWTOs, READMEs and so forth.
On the other side, the 'decision makers' (who not necessarily are identical to the most technically educated/interested people) might prefer an abstract such as 'how to leverage the success of your e-commerce using a new IP stack' or 'IP for decision makers' or 'Huh? they can do dat with l33nux?'.
I have an elderly version of 'Linux the complete reference' by LSL which contains many (Mini-)HWOTOs and other stuff. Much of these documents deal with Linux 1.x versions and were refreshed with 2.x delta stuff. These readings still hold true for the 2.2.x kernels and probably will not be 'wrong' or 'untrue' for the 2.4 kernel.
My advice: Keep your book as it is and add the delta work as a smaller manual. That way the insider only needs to have the addendum with him/her and can leave the bulky Part I at home/office. Make these addendums subscribable, in both preprinted form as well as .PDF (no affiliation whatsoever) documents to download-after-pay. Or try to have one of the larger distros distribute your book. ('That manual deals with the TCP/IP kernel of Bonzo Linux in special but may also provide important informations for other distributions.', just like we see that in every second samba or firewalling book). You may even add a CD-ROM with a GPLed version of Dah One That Sponsored Thy Book.
Use The Source, Luke!
now's the time to give to the community.
How about we let people decide for themselves whether - or if - to "give to the community". Bitching about how someone "won't share" is a whiny, sanctimonious attitude more worthy of socialists. Waste your points and moderate this down all you want. My karma is descending toward the new limit of 50 anyway.
I don't neccesarily think this is so. More people would give your more editing, more oversite to make sure one person is not writing garbage, more orginization, and more mouths to feed. Many will say that linux documentation works this way, I would disagree. Consistent style and presentation goes a long way toward making the book usefull, understandable, and ultimatly marketable. More cooks spoil the brew (in writing, not Coding, although I could argue that is true as well).
Gavin Fischer
Apply for a teaching position at a university? Maybe they'll print your book... yes, they may charge in excess of $200 for it, but you'll be paid to teach the material you're writing about.
Personally I don't see the value of printing the book. I imagine O'Reilly isn't interested because it wasn't a good seller. This is no reflection on the quality of the book (I've skimmed it and put it back on the shelf), just a reflection on the size of the market.
(For those going to respond that Linux is huge, yadda yadda yadda, I mean a small market of Linux developers which work on TCP/IP programs, and have found the existing code, documentation and community support insufficient.)
The market of people willing to sign up for a detailed course on Network protocols, at which the core material is Linux's TCP/IP stack might be much more lucrative.
This turned out to be a fairly simple problem to solve -- indeed, I found several solutions.
For those people who send cash, all we would need to do is sort by currency and collect it until we have enough of a particular currency to go to the Reno currency exchange service. We discovered these people when I bought a book on eBay from a guy in the UK. (Then there are other uses: as my co-author suggests, a single subscription in small-denomination ruples might provide enough high-quality banknote paper to wallpaper the bathroom.) We would lose a little in the exchange, but that's a small price to pay to permit our content to be used world-wide.
For those people who send checks et al in non-US currency, our bank is willing to accept batches for a nominal fee.
In short, no problem!
Hmmm...in the book trade, that's called "remaindering." This process is the source of those books that appear on the sale table, the books that sell for $1, $3, $5, or for those really large coffee-table clay-coat books, the ubiquitious $9.98 price. :)
Perhaps an example closer to the mark is the one used in the stock business. You pay one hell of a large price for real-time stock-ticker feeds, but for those people who don't need up-to-the-second information the 20-minute-delayed feeds are considerably cheaper. Perhaps this is the model to keep in mind as we explore your question.
Part of the process of publishing the book on-line will be to go back to previously published information and release updates -- a living book in every sense of the word. Moving older, slightly outdated information to a publicly-accessible reading area would be a reasonable way to "recycle" those words that would help the cash-strapped student, while keeping the real value of up-to-date information for those readers with both money and interest.
I'm not ready at this time to commit to doing what you have asked, but I am bringing this up with my co-author and we'll make a decision. We will publish an answer to your question on the Web page.
I have often wandered the same thing. Perhaps this is generational?
I too have a shelf full of books I constantly reference, but my brother-in-law, who is both younger and a better programmer, gets by with almost no books --- but a lot of Altavista queries
"one treats others with courtesy not because they are gentlemen or gentlewomen, but because you are" --G. Henrichs
-
but they apply just as much to all the kernel hackers
Yup - but remember: there is a demend for the Linux kernel to be hacked -> Alan Cox hacks the Linux kernel [because he wants to] -> Red Hat pay him [so he can eat]. This book needs updating to 2.4 -> These guys want to do it -> who will pay them?There is nothing wrong with looking for a 'Red Hat' to fund your project.
-
the issue isn't "how do we fund documentation writers" but "how do we find documentation writers who don't need/want to be funded"?
Is "how do we find kernel hackers that don't need to be funded?" an ideal goal, too?-
If you love to document the Linux TCP/IP stack then do it. Period.
If Red Hat hadn't hired Alan Cox, then there is a danger that Linux would have lost one of it's most valuable contributors. The man needs to eat.It is not inheirantly wrong to hope to be paid for hacking Linux.
Keep writing it on the net as long as contributions keep rolling in.
In Murphy We Turst
My advice to you, then, would be to adopt the business plan that we're going to see a lot more of in the future: Turn your content into a service. You could either charge a subscription (as you suggested), or use cookies to track how long a reader was on the site and bill them using a low hourly rate. Just like how open source software works, this guarantees you an income even when other people reproduce your works (which isn't necessarily bad, of course!). If you're selling downloads, people can easily mirror the pages elsewhere, and you lose your money. But mirroring the server power that keeps a service running isn't easy -- they'd need to charge, too, which means that they're not really competing with you.
A Eudora-type model probably isn't a good idea -- few people are going to go out of their way to pay to eliminate the ads, and the choice between "free, but ads" and "pay for no ads" could be difficult to pitch to both consumers and investors.
Best of luck to you regardless of which method you choose -- I've consulted Linux IP Stacks Commentary quite a number of times, and I'd love to see an updated version of the "book"!
I think it would be interesting for you to try all three of these and then post the results publicaly of which ones are bringing in the most money:
Lobby for someone to help foot the initial bill. (IBM is betting the house on Linux...I bet they'd do it.)
Accept PayPal donations from individuals/small business.
And, have a low ($5/month absolute tops) subscription rate and to keep the site updated regularly. (billable through PayPal!)
Josh
Plenty of projects, not enough developers...
None of the presented options are really exclusive of the others; myself, I'm rather fond of a combination.
Certainly, give free access to part of the material to help the community. No one will begrudge you banner ads on that portion; the community has become used to overlooking them, for the most part, as long as no extraneous JavaScript windows go popping up.
Certainly, sell subscriptions. Real Programmers(tm) are used to subscribing to various publications which track fast-moving standards. At $12/yr, this is cheaper by an order of magnitude than most.
Have each section attached to some means of readers (perhaps only registered readers) leaving marginalia. During the update sweeps, some of this marginalia might be folded into the main text. This gives you Open Source/peer review flexibility without having to embed it right on the page immediately, Wiki-like.
Overall, I think you're in a good position, as long as the interface is clean, consistant, and direct.
-- Riding the Winds of Fires Lit in Ancient Days
I'm sure there is no lack of people in the Linux comunity willing to donate some docs they've put together themselves in exchange for credit in the book. You're trying to solve a "time to market problem" and the only way to solve that is working in parelell with other linux power users.
All the arguments you use for not just writing it without funding are perfectly valid--but they apply just as much to all the kernel hackers and other Free Software/Open Source programmers as well. To be perfectly frank (and no offense to the submitter) the issue isn't "how do we fund documentation writers" but "how do we find documentation writers who don't need/want to be funded"?
My advice is: If you love to document the Linux TCP/IP stack then do it. Period. You can put kibbies in the cat dish via other paid work. Conceivably someone might later want to give you money/stocks for the effort you put in, but that's not the reason you should be doing it.
There's no point in objecting to my advice by saying "but how'm I gonna eat?". Either you want to do this badly enough that you'll do it no matter what--or you won't. That's all there is.
--
Bid on me!
Linux MAPI Server!
http://www.openone.com/software/MailOne/
(Exchange Migration HOWTO coming soon)
Sorry, but my money means as much to me as your does to you - I'm not interested in creating a charitable fund to subsidize the production of a half-decent book. I've read parts of this book and its not one I would recommend or buy again.
I think the market has already passed judgement on this publication.
This book provides valuable commentary on why the good things in unix are good, and why you should repeat these practices. Its a quick read - you can probably read the whole thing on one transcontinental flight. Highly recommended. Order it here
I believe this to be a fair question, and one deserving of an answer.
Stephen Satchell (that's me) started with ARPAnet back in 1972 at UIUC, did embedded programming for products in the banking and publishing field up until 1987, a part-time product reviewer starting in 1984 and thrust into full-time professional writing in 1988, first as a freelancer and then as staff at InfoWorld magazine. Even as magazine staff I wrote programs, including benchmarks. I've worked with the SPEC series, porting it to a couple of environments. Since that time I've moved between industry and journalism, writing in both places. Today, I'm working with a number of magazines to illustrate the Carnivore problem, network security issues, and (today) got a letter inviting back onto a product review board. What goes around...
Oh, yes, you will find me contributing to a number of the Linux mailing lists from time to time. I sell Linux-hosted products. I use Linux extensively in my test consulting practice.
Ms. Clifford's writing background includes a number of books, both non-fiction and fiction, editorships at magazines such as VLSI Design and InfoWorld, regularly wrote features on science, computers, technology, and medicine, and even ran a science fiction fan magazine with her ex-husband...complete with Varityper CompSet typesetter and film developer in their Santa Clara living room. I met Ms. Clifford at InfoWorld, and from that initial meeting (and that tape-drive product comparison) began a working relationship that continues to this day. About 1.2 million words has come out of the collaboration.
Today, the two of us live in a duplex building, her on one side of the firewall and I on the other side. Fiber optics isolate our two networks. A love for writing binds the two sides of the house together. The cats (on both sides) and the aforementioned firewall keep us sane.
I've seen a lot of systems popping up on the web over the last few years to allow dynamic additions of content to an information system. Things that allow commentary to be added to webpages, which others can then view; sites like Everything or Everything2.
Why not such a system for documenting code? I know that systems for publishing and linking code to itself exists (like LXR). How about such a system that would allow links to be placed in the text to user-contributed documentation? Said documentation could be anything from "this statement is doing such-and-such" to an overview of an entire module.
This documentation would be user-contributed and, of course, user edited. Editing would need to be done based on a voting system... just saying whether a given bit of doc is useful ought to be enough. Attribution is easily done, as well.
The hardest bit would probably be telling the system where you want to place a link. Do you want to doc the line? The function definition? That word? These 3 functions? That bit of code and that one over there in a different file that happen to work together? Where does the link go?
Anyone have an idea on how to do that? I know I'm up for contributing to the development of such a system (playing with Zope has gotten me interested in dynamic web stuff).
---
END OF LINE
With all of the funding that linux development is receiving from the likes of HP/SGI/IBM/Redhat/VA/etc you should look into seeing if any of the companies with deep pockets have a documentation budget and if you can get in on the action. I would think that SGI, with their focus on high performance computing, and scaling to large numbers of cpus would have a particular interest in having the network stack well documented so at the very least their own engineers could better work on scaling it.
When information is power, privacy is freedom.
Books are close to useless for computer documentation. I find linuxdoc more than adequate for all my documentation needs. A printed version would be useless to me since:
- I would probably never read 95% of it
- It would be a huge pile of paper
- It would be difficult to update
- It would be expensive.
Now linuxdoc is not perfect, it is often difficult to find the right document for instance. But once youhave it, it is easy to find out whether you have the latest version, to find relevant related material, cut paste pieces of code/shell script, etc.
Now, I can't imagine that there's a lot of people in paper documentation of an obsolete TCP stack. An online version of this documentation could have been put on the web before it was completely finished, allowing people to comment on it and maybe even contribute to it. That also would have meant that there was at least some documentation while the stack was not yet obsolete.
So for the next version of the book, I strongly recommend not to bother with a paper version. You'll do your readers a favor and make the documentation more usefull. Of course you won't get royalties, but I can't imagine that your current TCP stack book is a bestseller either.
Jilles
I'm suprised no-one else mentioned this, since it was invented to cover exactly the situation you're in. In Schneier and Kesley's model, donations are held in escrow, until the publication date. If the funding level you asked for wasnt met, you wouldnt finish the work and money gets refunded; and so on. They wrote a paper on this which describes the process in detail : http://www.counterpane.com/street_performer.pdf
/. before in the context of Stephen King's last work.
This is no pipe dream, IIRC this has been discussed on
Isn't that exactly what this is? Why the spin to make it sound like something else? This isn't a case of the Stupid Mass Media and Public At Large conspiring to misunderstand the Linux Phenomena. It means exactly that: there is a lack of interest in this project. There is no question about how "some people" see this.
If there was enough interest in the book, people would have bought it and Coriolis wouldn't have said no to paying for a second one. If there was enough interest in writing one for free, it would have been done. Free speech works best when it's combined with free beer. Most open source programmers don't seem hugely interested in (or capable of, honestly) writing good documentation and most writers don't seem willing to donate the massive amount of effort required to write a book and then give it away for free. After all, not a lot of writers can sell support contracts for their books and Red Hat, SuSe, Mandrake, et al seem more interested in creating yet another graphical install tool rather than creating good documentation.
How interesting that yesterday's /. carried the wonderful article on Richard Stevens and today the writers of a work bearing a striking similarity, at least in subject matter, is described. I have two comments. First, I have looked at the Coriolis book and it is no where near the quality of the Steven's books. Now I don't mean this as a criticism, except in the constructive sense. The authors of the Linux stack book should realize that most people are going to exepect at least the quality that Stevens put forth for BSD or the book wont be very interesting. Second, were the authors to aspire to that level, it seems reasonable that Addison Weseley might be interested in taking over the project.
My opinion is that the 2.4 TCP/IP stack will be around for a long time, and with the improvements over 2.2, deserves a treatment in book form similar to the Stevens efforts. I would applaud the authors if they feel this way too.
Frank W. Miller
VA Linux Systems pays Malda and Hemos. VA Linux also runs SourceForge.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
while the collaboration software enforces the rules to keep the whole thing consistent.
What is required to be consistent, in this case, is the writing style. Collaboration software makes no pretense of being able to fix writing style.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
I'm suprised no-one else mentioned this
You mean like #10?
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?
I'm surprised no one yet has mentioned this, so I will -- the GNU Project is very interested in having Free documentation for Free Software. They rightly regard it as essential for the software to be useful. The subject matter of your book is:
1) deeply technical and narrowly focused. There will not be a mass market for this book, even within the technical community. Therefore, a print publication is probably out of the question at least initially.
2) always changing. This means that for the book to remain useful to anyone, it will need constant updating as the software it documents is changed. Therefore, I agree with the other posters who have said that you should probably publish this in electronic format (SGML-based, like DocBook), using a license that allows others to maintain it. I recommend that you take a look at the GNU Free Documentation License.
The FSF doesn't have a lot of money to pay developers for software or documentation, but they do have some resources. Also, they have contacts with many other groups in the Free Software/Open Source movement, and might be able to solicit funds from Red Hat, SuSE, O'Reilly, VA Linux, etc. if they couldn't cover the costs themselves. Finally, the hackers who would be most interested in buying your book will be much more likely to make donations to finance the effort if they know that it will remain Free Documentation (ie: FDL'ed).
With this model, you probably will not get royalties, but would instead be paid a lump sum for the work, and then paid additional amounts for revisions over time. However, due to the very narrow appeal of a book like this, it would probably be more profitable for you than hoping for a conventional print publishing contract. You will probably never get one, and even if you do, the circulation of the book would be so small that the royalties would be negligible.
Please consider contacting the FSF about this possibility -- it's worth a shot.
Alex Berkman
...I would hate to see the publisher who would ignore it.
<O
( \
XGNOME vs. KDE: the game!
Will I retire or break 10K?