Funding Linux TCP/IP Stack Documentation Project?

satch89450 asks: "I am one of the authors of the book Linux IP Stacks Commentary published by Coriolis Press. This book comments the TCP/IP code in Linux kernel 2.0.34. The history of the book is described here in detail, including our reasons for 'leapfrogging' the 2.2 releases and going right to 2.4. Yes, it's long past time to update the book, especially as kernel 2.4.0 has many, many changes in the TCP/IP code and is in test release as you read this. Our problem is how to fund the effort. Coriolis appears not to be interested in another round at this time. Heather and I are both professional writers, and that's how we make our living. Given the amount of work, donating the effort is out of the question -- it wouldn't keep kibble in the kitty bowls and have the material available in a timely fashion. We're looking for ideas." One of the largest complaints about Linux is that there is a lack of high-profile documentation. It would be sad if this publication were not made simply because of the lack of funds (which some people would see as a lack of interest) necessary to complete it.

"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:

1. 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.)

2. 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.

3. 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?

4. 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)."

Comments

Ah, the old content funding problem

[vertical-limit]

This looks just another example in a long string of recent difficulties funding content-based services. Companies are steadily waking up to the fact that banner ads aren't a very effective means of promotion for their product -- indeed, much of the /. readership probably has them automatically removed. As banner advertising rates plummet, it's going to become more and more difficult to run a successful content-based web site. (Obviously, retailers like Amazon or eBay won't be affected... they do have revenue, even if it's not enough to make a profit :) ). Sure, Slashdot and Wired will stay around, but do you really think myQuakeNewsPortal.com is going to stay in business?

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"!

Possible Solutions

[thantos]

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.

Street Performer Protocol

[Bazzargh]

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

This is no pipe dream, IIRC this has been discussed on /. before in the context of Stephen King's last work.