From: Andy Oram Subject: The conference that made me change my mind on the term "free software" To: kfogel@floss.red-bean.com Date: Fri, 19 Mar 2004 15:26:25 -0500 (EST) http://www.oreillynet.com/pub/a/network/2002/10/11/platform.html Why Human Rights Requires Free Software ------------------ From: Andy Oram Subject: Article I mentioned on the opening of documentation To: kfogel@floss.red-bean.com Date: Fri, 19 Mar 2004 15:18:58 -0500 (EST) Splitting books open: thoughts on the digital future of technical documentation I'm talking today about the future of technical documentation. Raising this subject immediately brings up the commonplace observation that this documentation will all go online. I am actually of this school of thought myself, and I will not disappoint you by offering a contrary point of view. The tentative moves online that are taking over journalism and pop music will soon apply to technical information as well. The advantages of going online are just too overwhelming to argue against: a book doesn't have to spend a month at the printer, it is freed from many layout complexities, editors can fix errors immediately, and publishers can eliminate the middlemen (distributors, vendors) and distribution costs are practically nil. Furthermore, surveys and book sales reveal that the change is well on its way. People increasingly search for technical information on the Internet rather than trusting to printed books. So I can vouch for what all the other observers say: documentation is going online. I'll see their bet and raise them two, by stating some other distinctive characteristics of the technical documentation of the future. In addition to being *online*, it will be *freely distributable*, which means that conventional copyrights will not apply and that the usual form of per-unit pricing will have to be supplanted by other forms of compensation; and it will be *localized and topical*, by which I mean many small documents with very specific, immediate goals will replace long-lasting tomes that appeal to wide audiences. --- Slide Title: Characteristics of future technical documentation * Online * Freely distributable * Localized and topical --- In this talk, furthermore, I'll try to take the next step that other observers have not yet taken and ask: What do we lose in this new environment? What important benefits do conventional books offer that the new media will lack? And how will we replenish what we have lost? Ultimately, I will show that communities have to provide in a collective manner what readers used to derive from good books. To understand the traits of documentation in the future, let's look at some interesting trends in documentation of the present. ----------------------------------- A comparison of publishing programs ----------------------------------- For a few years I have been trying to meet the challenges of new computer software by producing good books in the conventional way I know how. A popular piece of software becomes a de facto standard. As an editor, I respond by applying the best skills that my author and I have to offer. We carefully cull the topics that readers need, eliminating things that are too advanced, too obscure, or too rare. We analyze our target audience and pitch the material at just the right level of detail, carefully filling in background before attacking complex topics. We produce an elegant, unified, carefully structured, well-paced, superbly written, text with a positively Aristotelian balance and argument. A competing publisher does none of this work. Instead, as fast as they can, sometimes throwing a dozen or more authors on a work with no attempt to calibrate and coordinate their output, they produce a thousand-page, overstuffed tome, shoveling in every topic they can think of, paying no attention to the diversity of audiences and knowledge levels addressed, and making little attempt to move at an even pace or provide background before instructions. --- Slide Title: A comparison of publishing programs On the left, a picture of a small book shining with elegance, careful structure,etc. On the right, a messy, overstuffed, ugly tome --- And which book sells better? The overstuffed tome! --- Slide Title: The marketplace winner Same as before, but missing the book on the left. Just the messy, overstuffed, ugly tome on the right. --- What went wrong? Why am I not rewarded for all the hard work, the careful analysis and planning, the superb artistry? Of course, I cannot blame the publisher of the tome. They're doing what people want them to do. This is not an aesthetic contest like the music of Bach versus Telemann, where history will judge. Whoever wins in the marketplace of technical documentation must be right. But no, they're not right. The outcome offends my Aristotelian sense of logic, I admit, but beyond that, the result leaves people not getting what they ultimately need. The overstuffed book is tasty but less filling. And you know that the purchasers won't read those thousand pages; they're exceptional if they ever read a hundred. ----------------------------------------------- The reasons people don't buy good documentation ----------------------------------------------- We know how people read technical documentation. Briefly, they don't. Not only do they refuse to read the book in the order it's written; they try to avoid reading it at all. They search for an example and copy it. If it doesn't work, they grudgingly backtrack and look at the explanations that accompany the example. They lather, rinse, and repeat until they've picked up enough information to solve their problem. Little attention is paid to the ideal of general understanding; if readers have another problem to solve they have to start the process all over. I think the problem lies in the gap between the conventional literary education some of us had, and the experience of the general reader in the age of McLuhan. The sociologists have enjoyed a field day describing the death of literature and the inability of the general public to absorb a written text, so I won't go over all those arguments, and I certainly don't want to come across as an old fogy. Oh drat! I am an old fogy. It comes across in too many ways. I talk about concert music; most people don't even know the term, and just call it classical music. I press buttons directly on the TV set instead of using the remote, and when I do use a remote I call it a remote control. I believe in labor unions. And when I edit books, I adhere to the values of classical exegesis. Let me interject here an admission that I do provide some books of the new type, and my employer O'Reilly & Associates provides even more. In fact, one of the most popular books I've edited falls into the thousand-page overstuffed category; it's called *Linux in a Nutshell* and it's in a standard, alphabetical reference format. We have reference books at O'Reilly, and we have collections of snippets of useful tips, which we tend to call Cookbooks or Hacks. We're aware of what people want and we're moving in that direction. But these books do not provide everything the old-fogy types do. Here are some useful characteristics of the traditional style of book. --- Slide Title: Old-fogy values in documentation * Pace * Audience * Structure * Models --- First they have *pace*. They lead the reader gently into new territory, anticipating what concerns are on the reader's mind and conducting her as if pacing through an argument from what was said earlier to what is said later, all in a language she is expected to understand. Then they have a sense of *audience*. They spring from an understanding of what the user is trying to do, along with what she needs to know and what she doesn't need to know in order to accomplish the tasks. They have *structure*. Background is provided before the tasks that assume that background. Terms are defined before being used. Simple tasks are laid out before more complicated ones, and essential tasks before less common ones. Finally, they offer *models*. They use metaphor, experiment, and example to give the reader the tools she needs to solve problems herself. The readers take from it more than working examples; they take from it *power*. Readers are too impatient, and haven't been trained to be careful, thinking readers, so they don't appreciate that they are losing these qualities when they reject good documentation. And to tell the truth, they haven't lost very much. Why? Because technical fields provide very little in the way of good documentation. That's the fault of publishers. From the time readers enter elementary school to the time they pick up a manual at their jobs, they come to believe that books are just ill-organized, boring composites of hard-to-understand facts. They have too few examples of anything else. And if all the conventional documentation were to vanish today, little would be missed. People don't realize what questions a good document can fill in. The obvious questions, "What are this and what does it do?" are just a tiny part of the information people need. Even "How do I perform this task?" is a superficial question. Consider deeper questions such as: "What is the range of problems this technology is designed to solve?" "How do different parts interact and alter each other's behavior?" "What are the strengths and weaknesses of different solutions?" "What I am responsible for once I take on a role in relation to technology?" "How do I lay the groundwork for flexibility and reliability as my system grows?" These are common questions--or should be, except that people don't know how to ask them. But they need the answers in order to achieve lasting success. So communities of technical users have come over time to fill in the gaps that are left by inadequate documentation. Somehow--with great difficulty, with much wasted effort, with many projects abandoned in disgust along the way and many talented people leaving technical fields altogether--the communities put together the information they need. And that is our salvation. The community will provide what technical documentation cannot. ---------------------------------------------------------- Reasons traditional technical documentation will disappear ---------------------------------------------------------- As much as I like traditional books--and it should have become clear by now that I love traditional books, when they're well done--from the point of view of my job as editor, I'm the first to applaud their going online. Let me tell you, I hate the process of producing a traditional book. The author and I do our work; we have something in close to publishable state, and we know that the work of the copy-editor, proof-reader, indexer, and artist will require only a couple weeks. The creative input is all ready quite early, but still many weeks are required checking the layout and preparing the book for print; then the seemingly interminable wait while it is at the publisher. No wonder every author feels a great swelling of excitement when he first beholds the published book--he's waited for it so long! As an experienced and jaded editor, my reaction to the published book is more like: "Oh yeah, I worked on that once." As for my claim that books will become freely distributable, I don't have to repeat the arguments that have been aired over the past decade. Once the book goes online, it's ultimately out of control. One can win loyalty through various tricks such as providing frequent updates and building communities with reader commentary. But well-known social and technological forces undermine such short-term fixes. Anyway, as I will soon discuss, documentation will increasingly arise within the community. People will do it for reasons other than royalties. Perhaps the most interesting difference in the world of technical documentation is that much of it will be localized and topical. That is, documents will be produced for particular needs of very specific audiences at particular moments in time. We already see that in journals, including online journals. An article may be wildly popular for six months, but rarely do people go back to it after that. Soon enough the moment when it had value has passed, and the target audience has passed on to new understanding as well. Only a few documents with enough depth and historical value to be considered "classics" will be visited for years afterward. This presentation, for one. Traditional documentation conforms to traditional literary analysis, which stresses the Text with a capital T. The text with a capital T is more than just a book you hold in your hand. It is a sacrosanct entity that humans must approach on an equal or even subordinate footing. The Text is meant to stand alone and unaltered; one can reinterpret it--and in fact, one is expected to come to it again and again over one's lifetime and see it in a new way each time--but one cannot change it. The original model for a Text with a capital T is the five books of Moses, which to this day are written on goat skin in the ancient form of a scroll and paraded solemnly through a crowd of Jewish worshipers one to three times a week. But there are many nonreligious Texts with a capital T as well: Homer, Shakespeare, and so on. Even Tolkien--talk to readers who are upset at how the movie makers changed a scene from Tolkien. Ironically, the most honored Texts, which no one can touch, are those that have become corrupted over time and may even exist in multiple divergent forms. So much for Texts with a capital T. A few Texts with a capital T exist in technical documentation, but clearly this approach does not fit the field very well as a whole. Let's go back to the thousand-page, overstuffed tome with topics randomly shoveled in; the document that I presented earlier with such admiration (for its success in the market if not its intrinsic quality). Don't its high sales prove that the technical book market is alive and well? That would be a natural assumption. But on the contrary, the dominance of this kind of text augurs the coming end of the technical book. As I've pointed out, people don't read this book the way a book was meant to be read; they don't benefit from the pace and structure of a traditional book. People who dip into books like these to get an example or a page of explanation can just as well get the information from localized online documents, and soon they will. The overstuffed books succeed because society has built up an infrastructure for distributing books over hundreds of years; we're very efficient at making books, spreading them to stores, getting them reviewed in influential places, and so forth. But even this impressive network will not compete with the future state of documentation forever. And once you've resorted to this kind of book--once you've stuck as many pages into a binding as you can without breaking it, and shoveled in all the facts you can imagine to be related to the topic, and rushed it to market as fast as you can, and lowered the profit margin as much as you can afford--you have nowhere else to go. This is the end of the line for the technical book. What's developing instead in technical documentation is a very contextual text. Writers find it easier to address an immediate felt need than to produce a lasting document for all readers over a long period of time. And I think multiple, divergent texts will soon become the norm in technical documentation. For instance, instead of one introduction to the database called MySQL, there will be an introduction for Oracle database administrators moving over to MySQL, an introduction for Web designers beginning to think of incorporating the MySQL database into their sites, and so forth. Documentation will splinter. How small can the splinters get? You will soon see. ---------- Baby steps ---------- At O'Reilly, we are way ahead of most publishers. We are heading with deliberate speed into the new world of documentation. I'm referring to Safari, the subscription system we created for our books and have now spun off to share with other publishers. The success of this service, as demonstrated by increasing licenses and reader praise, reveal the value of its contents and the care that went into its design. But our current implementation, as impressive as it is for the early twenty-first century, and as unique as it still is among publishers, remains quite timid compared to what could go online. There are a thousand innovations we haven't tried yet. Putting print books online is just a tottering baby step toward the future. It's like the quaint early days of movie making, when someone would just set a camera up in front of a theater stage. We've gotten to the point of incorporating a few jump-cuts (links) but little more. I happen to know that the managers and designers of Safari have many enhancements they'd like to try. To sink a ground-breaking system into the ground takes time, if you want to do it right. And I believe they have to wait for more revenue to come from the current system so they can afford to fund the next improvements--a common chicken-and-egg problem, which we hope to turn into a virtuous cycle. But part of the reason I think Safari is improving rather slowly--and I have to beg pardon from its managers for saying this--is that it lacks competition. So I'm asking other publishers: please go online. Learn what it takes to create online books, and become masters of it. Join Safari if you like, but make intelligent demands on it. Force O'Reilly to innovate, in order to improve the experience of readers everywhere. How must the art of writing change when moving from print media to online media? Some of the answer has been explored by Quest Software, a company that develops a series of desktop reference tools called Knowledge Xpert. The role of Knowledge Xpert is provides users with instant access to high-quality guide and reference content within the context of their work. When Quest takes print books and adjusts them to Knowledge Xpert, they find it important to make the following changes: * Remove dependencies on surrounding context. The dependency in print documentation can be easy to pass by, such as "We've seen that..." or even more subtly, "It's obvious that..." In the latter case, something is supposed to be obvious because the reader has seen earlier discussions. Quest has to replace such casual assertions with links to background material. (As we've seen, given the way people bounce around in technical documentation, it may be unwise even for a print publication to assume context.) * Shorten material. Online readers are less interested in having a stage set properly than in getting to the point. * Divide content into smaller stand-alone units. While a book chapter might cover a miriad of subtopics, an online chunk of text needs to be focused on a single concrete, identifiable topic. * Provide succinct but clear topic titles. If a user has to consistently search past the title into the topic text to find relevant content, he will get frustrated and likely give up using the online resource. ------------------------- Other hints of the future ------------------------- To find out what technical documentation of the future will look like, one needs to look at how people in technical fields get information now. Typically, someone will start by reading a well-known journal, which may be on- or off-line. This will point him to documents with less visibility, when are more often online. And to even less formal sources of information, such as mailing lists and newsgroups. He will start to read one of these evolving communities, and perhaps post questions and experiences of his own. Answers to his questions will drive him further toward expertise. Along the way, he might very well consult traditional books and take courses. All these things, taken together, form a rich environment for learning that is unique for each person. --- Slide Title: Rich environment for learning Clusters of ellipses representing the various steps in the previous paragraph. --- Now we see what is compensating for the lack of pace, audience, structure, and models in technical documentation. The community as a whole compensates. The basic questions I mentioned earlier are answered in one-on-one exchanges or informally exchanged documents. People create a lot of ad hoc explanations and do a lot of pointing and linking to them. The community is the best source of training because every individual starts in a different place. I'm very conscious of the strengths of professional trainers, and even more of professional writers, but most learning goes on informally in the middle of a project rather than from a Text with a capital T (or a Seminar with a capital S). People learn what they need from other people like them who have been through what they're going through. The dynamics of learning push communities toward ad hoc measures, and simple economic pressures ensure these will be short interventions aimed at an immediate, short-term effect. How short, localized, and topical can documents get? Here's an example. --- Slide Title: A sliver of the technical documentation of the future

Q I'm rather new to administering BIND, and I tend to make some syntax mistakes. Is there a tool out there that will debug my changes before I start/restart BIND so that I don't take the nameservers out of commission with bad zone files or config files?

A You don't say which version of BIND, so I'll presume that you're running the latest release of BIND 9. If this is the case, there are two programs that come with the distribution that will do exactly what you want. To check your named.conf syntax, run named-checkconf. It checks the syntax but not the semantics of your configuration file (with no arguments, it defaults to /etc/named.conf). To check your zone files, run named-checkzone:


  named-checkconf /etc/namedb/named.conf
  named-checkzone your.zone /etc/namedb/your.zone.file

For more information, see the man page for each command.

(Reprinted by permission from the November 2003 issue of Sys Admin.)

--- This sample exchange was taken from the popular Sys Admin magazine, which exists in both a print version and an online version. The exchange is typical of the question-and-answer columns that appear in computer journals, both printed and online. While questions like this get asked on mailing lists and newsgroups all the time, this particular question and answer must have been considered worth publishing because the editors are convinced many people have the same problem as the original questioner. This kind of exchange clearly teaches something and solves someone's problem. This tiny point of knowledge, this intersection between the trajectory of the questioner and the respondent, is a key part of the information space for this technology. Notice that I've officially obtained permission from Sys Admin to reprint this little snippet--it's a valuable piece of intellectual property for them! But think about how much the person needs to know in order to benefit from this documentation. The questioner is obviously an experienced administrator who has already finished configuring a complex tool. He or she also has to be experienced enough to anticipate when problems can arise and take servers "out of commission." He or she has narrowed the problem down to finding tools that can debug the configuration. In short, the questioner has done a lot of work in order to hone his or her needs down to an answerable question. Furthermore, the answer simply starts him or her off in the right direction; it points to places to get "more information." If this kind of exchange is the outline for future documentation, it's high time for experts to examine the community process for generating information and try to optimize it. The basic questions won't be answered for everybody unless we're more conscious of what we're doing. The community way of doling out information has proven more effective than attempts to produce Texts with a capital T (attempts that rarely achieved what they should have) but the process has to be tightened. We must be conscious of what people used to get from good documentation, and what the community process needs in order to fulfill those functions. Part of the community education process is maintaining its own history. Have you seen a posting on Slashdot that enlightens the readers that information was offered in an earlier thread some months ago, a thread that itself contains a posting that points out the same information was offered in an even earlier thread, and so forth? When I see these chains of attribution and repetition, I feel on the one hand like this is a big waste--can't the community just write the information out once, really well, and remember it? But this kind of continual reminder is the community's way of educating the people who join at different times. -------------------------------------------------------- Suggestions for improving community response to learning -------------------------------------------------------- As communities recognize more and more the burden they must shoulder to educate their members, new forms for this education will emerge. They will probably be better if we build them consciously. To start with, I would like to suggest some critical improvements technical communities could make to improve the learning process. --- Slide Title: Improving the community response to learning * Create ad hoc documents and point people to them * Promote active community participants to become formal contributors * Incorporate professionals into community documentation * Nurture new users; don't repel them * Enhance rating systems --- * We should formalize the process of creating ad hoc documents and pointing people to them. Many useful explanations are buried in emails or newsgroup postings that are indistinguishable from the thousands of others that pass by. Occasionally someone pulls out an explanation that he recognizes to have greater value than the usual run of postings, and puts it on some web site. These documents bear no relation to each other, though, and people are left on their own to do searches or hop from one document to another in the quest to assemble their personal learning experiences. Mail and news postings, of course, contain pointers already. At one extreme, a contributor to one high-traffic newsgroup became famous for responding to newbie questions with one-line responses consisting of a page number from a book he had written. A lot of people seemed to think that was tacky. I consider it quite legitimate because, after all, it was an O'Reilly book. But in general, we should recognize when an explanation has been done well and reuse that explanation instead of typing up something fresh each time. On the other hand, we must recognize people are different and require either slightly different explanations or slightly different paths through the explanations. Formal repositories for ad hoc documents and pathways through documentation--flexible pathways allowing multiple traversals--would speed up the learning process. Wikis are an impressive development that concentrate the collective knowledge of a community. I originally assumed Wikis could not succeed because they don't embody ways to resolve disagreements or evaluate the value of submissions, but communities seem to have worked out these issues through various channels. How this works deserves more study. * We should actively seek out people in our communities who show the potential for contributing documentation, and directly pose to them the opportunity to contribute. We should designate people to watch mailing lists and newsgroups to find out who shows up on them repeatedly and demonstrates both a keen insight and a zeal for sharing it in a positive manner (that is, not an immature tendency to show off, but a true desire to share knowledge and build up the knowledge base of the community). We should then approach these people formally and ask them to preserve their knowledge in more fixed documents of some weight. Conventional publishers do this all the time; community documentation projects can adopt the same strategy. When asking people to become formal contributors of documentation, we need to find incentives for them to take on the extra work. We need to find out more about what motivates them already. Do they just like the products they talk about and want to promote their use? Do they feel good helping others? Or, as is likely, do they hope for incidental benefits for putting themselves out front in the community. Perhaps they hope someone will offer them a job or take some training from them. We should offer some sort of tangible incentives when we want to raise their level of contribution. This leads to my next point. * We can benefit by incorporating the assets of professionals and instructional experts into community documentation. Right now, a person who wants to offer substantial wisdom in exchange for sustenance can get payment in only a few rigid ways: writing for conventional publication, leading seminars in established venues, or consulting. Meanwhile, there's a whole world of information documentation that could become better with a little oversight and dialog between professionals and nonprofessionals. Good editing requires a lot of training in the art of writing, bolstered by experience; nor can it penetrate very deeply into the needs of a document unless the editor has some background in the subject matter. To get to the point, good editing is expensive. It can be justified when producing a Text with a capital T, which is meant to last and reach far-away, unintended audiences, but it isn't economically viable for short-term documents that meet an immediate need and will then be forgotten. But a sense of pace, audience, structure, and modeling are still necessary for effective writing, even the most ephemeral documents. How can editors be put to best use, then? We must whittle down and extract the key value of an editor, so that an author can get what he or she substantially needs in a small space, just as modern doctors are required by health insurers to deliver the treatment that does the most for the patient while keeping expenses down. An editor may do the most good by talking to an author about just the introductory paragraphs of a document, teaching the author how to lead readers in and set a context. Or the editor may help explain the background that the author has to offer readers, or may look at the high-level organization of the whole document before the author starts, or may suggest metaphors and tricks for engaging the reader's imagination. (I'm just restating my same four values of pace, audience, structure, and modeling.) Currently, O'Reilly & Associates has a hundred or so highly trained people devoted to all aspects of gathering, shaping, and disseminating information. Their skills could be invaluable to those providing free documentation to technical communities. Should traditional documents disappear, many of these O'Reilly employees will want to offer their services directly to the community. And the same goes for experts throughout the world of information. We must have mechanisms--whether through subsidies, subscriptions, grants, or other measures--to make use of their talents. Moving from a model of pay-per-copy to a model of sponsorship by groups or organizations is radical, but not totally unprecedented. Lots of fine documents have been sponsored; one is well-advised to check carefully for evidence of bias toward the sponsors, but the model has produced some good results. And after all, what is it when companies reimburse employees for purchases of books and subscriptions related to their work? In fact, what are corporate libraries? In these cases, the company is subsidizing the development of the material, and such indirect subsidies can be an important percentage of all purchases. When the industry falls on lean times and companies stop these reimbursements or library purchases, publishers and bookstores feel considerable pain. * We have to encourage each individual to raise questions; we have to take on responsibility for shaping his learning experience. I know a lot of time can be wasted on lazy jerks, but that's a risk we have to take. The burden lies on the community to educate everybody. We have to stop lambasting newbies for asking questions that are answered in well-known specifications, Frequently Asked Questions lists, and other common documentation. The retort "RTFM" ("Read The F--- Manual") should be dumped from our ammunition bag. After all, the person asking the question might well have read the specifications and Frequently Asked Questions and might simply not have recognized that their answers addressed the question he's asking. Or he might not know these documents exist, or might have started looking through them and gotten overwhelmed. When someone demonstrates he is not making proper use of available documents (and they had better be well-written and relevant documents, before we cast judgment upon readers) our responsibility is to guide him through them, to turn him into an active learner and a participant in our community. * We should provide rating systems or other confidence measures. This is a very difficult problem with no perfect solution: you sometimes find highly rated postings on Slashdot that are nonsense, you sometimes find yourself cheated by well-rated sellers on Ebay, and you sometimes see lousy sites rise to the top of a Google search. But hey, people also get cheated by brick-and-mortar operators, get trapped in jobs they hate, and find out their best friends are two-timers. Life comes with a NO WARRANTY license in capital letters. The known failures of rating systems should not discourage us from using them. Community online documentation of the types I've been showing became popular partly because bad information is rarely dangerous. If somebody says "Try enabling this option and rebooting," and he's wrong, how much have you lost? Probably just the time it takes to reboot again. Someone searching for other kinds of technical information might have to consider the source more carefully. If somebody says "Try mixing these two chemicals," the downside could be a lot worse. But the use of all kinds of information depends on the reader's confidence in the source. So if we recognize informal community exchanges as an important component of our learning, we need ways to help readers know where to place the confidence. Communities are emphatically not limited to online interaction. Local communities are even more important for some people. One example of local communities that add crucial value are the Linux "install fests" carried out by Linux User Groups. For a long time (less so, by now) the chief barrier to using Linux was getting it installed on your computer. Many administrators claim that Linux is actually easier to install than Windows, but anybody could buy a system with Windows or Mac OS already installed, and for a long time this was harder to do with Linux. So user groups in major cities around the world organized install fests every few months, where they helped each other and brought new users into the fold. Communities can do an excellent job of educating members. But they are not always aware of what they do, and therefore they fail many deserving initiates. Here are some examples where the process goes wrong: --- Slide Title: Where community education often fails * English required * Cultural differences not respected * Different learning styles not respected * Gaps --- * Most technical communities are geographically global in scope. This is good because more people can get involved, more diverse points of view are represented, and knowledge can flow to countries and groups who currently lag behind. But there are drawbacks to this, the most obvious of which is that most information exchange takes place in English. There is often a smaller forum with limited information in some other language, but for the latest and greatest one usually has to turn to English-language fora. A conscious community can address this through the translation of key documents (as the Linux Documentation Project does) and through the deliberate maintenance of online newsgroups and mailing lists in different languages. * Communities also embody values, and the communities that promote technical learning often embody values with which many members are not comfortable. For instance, online groups that promote free expression and peer-to-peer education might not be able to serve people who expect more hierarchical and controlled interactions--or even basic politeness. This is a very difficult problem to solve, because people don't give up their cultural and personal expectations when they go online--nor should they be expected to. * Some people need special guidance, and while being perfectly intelligent may have learning styles that people in the community don't recognize. Perhaps they are not articulate enough to express their needs. Whereas these learners may have gotten attention and specialized training in a formal setting (or been able to understand a good book) they can quickly get left behind in a community setting and just drop by the wayside. We have little idea how many potentially productive members of technical communities we have lost this way. But a look at high drop-out rates in schools should alert us to the problem. Drop-out rates in K-12 education are much lower now than in previous decades, because teachers understand different learning needs better and are more committed to getting students through the system. This shows us how much of a difference one can make with increased caring and training in diversity. * Finally, community efforts at education are just plain haphazard. Rarely does somebody recognize an urgent need and step up to offer documentation. When a major new technology hits, people just muddle along. I don't see any way around making community efforts the substitute for the books we now know as our main technical documentation. I think the entry of the community as educator is a step forward, because the old technical documentation was usually inadequate, because ad hoc community efforts have done very well for many people, and because the tools for community efforts are providing more and better opportunities to carry out the job. But the community could do much better if their members were conscious of their heightened responsibilities, and if professionals in the fields of writing and education got involved. Those are some of the general tasks of the near future. We have reached the point in this presentation where I leave behind what Aristotle called "rhetoric" and take up what Aristotle called "dialectic." In other words, the speech is over and I'm open to questions.