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

This is becoming a fundamental issue

[tilly]

For instance the quality of many online magazines is dropping sharply because of it.

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, /., 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.

Which sucks if you want to produce some content of your own.

Cheers,
Ben

Re:So why is my shelve packed with O'Reilly books?

[morzel]

Books are obsolete. Save the trees. The information is antiquated before you get it.

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.

books24x7.com

[proj_2501]

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

Suck it up

[John Jorsett]

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.

Re:So why is my shelve packed with O'Reilly books?

[tylerh]

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

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

Accept Paypal

[The_H0und]

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

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.

I honestly don't understand the problem

[FascDot Killed My Pr]

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!

Re:Q:Time to market? A:Concurrent Engineering.

[satch89450]

Bring on more writers. 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.

Perhaps you haven't seen any of the CoriolisOpen Commentary series? The structure of the book is that the source code for the subsystem being described is published, with line numbers. Within the meat of the book, there are constant references to those line numbers. Furthermore, in the source code there are little markers showing where in the commentary the function or segment is discussed.

These design elements are unique to the series.

What Heather and I are considering is a completely different method of tying text to source lines, and using on-line presentation instead of using dead trees -- at least in the begining. The development process requires that text be coded in a certain way so that software can handle code and text separately.

Could volunteers work within the framework that we are creating? Of course. Indeed, Heather and I see some possibilities that we don't dare dream about until we see how this project works out -- if it does, we may well be paying authors to generate content for us in areas outside of the TCP/IP environment.

Crediting authors is not a problem. The way we plan to organize the book, having an author credit for each piece is simple, easy, and elegant. The credit would be there, with a link to a bio.

For the moment, we would need to do the first few contributions, to work out the bugs and to react quickly to feedback from the readers. There may be flaws in our basic design that may require time back on the drawing board to fix. When we get a presentation style that readers approve, then we can look at farming out some of the stuff.

Indeed, I'll say this right now, and loudly: I'll accept any offer from any victim, er, volunteer to write the sections on Routing. I'm not happy with my attempt at it.

Free Online Documentation Infrastructure

[Rhys Dyfrgi]

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

books are useless for shortlived information

[jilles]

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.

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.

Talk to the FSF about funding Free Documentation

[Anonymous Coward]

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