Community Network Services Frank Hecker hecker@home.com September 21, 1994 (Updated December 8, 1998 with new email address and URL) (Updated March 10, 1999 with new URL) Copyright 1994 by Frank Hecker. This is a draft document; please do me the courtesy of asking my permission before you redistribute it. (I will release the final version for unlimited public distribution.) This document is available online in draft form at the following URL: http://www.hecker.org/writings/services.txt 1. INTRODUCTION Over the last year or so I have been thinking about long-term technical strategies for community networks, and in the course of doing so found myself struggling to make connections between our ultimate goals in serving the community on the one hand, and the details of specific technologies on the other. Thus, for example, on the one hand we have a goal of increasing general public access to community information and resources. On the other hand we want to take advantage of new technologies like graphical user interfaces, ISDN and other higher-speed communications technologies, and new multimedia Internet services like the World Wide Web. How we do decide how best to use these technologies in support of our goals? One approach is to establish a conceptual "middle ground" between goals and technologies. In particular, I found it useful to think in terms of the various abstract services that a community network might provide. I use the term "abstract service" (or simply "service") to refer to general capabilities which the system might provide to broad classes of users, and which those users might use to solve problems and meet their needs in a number of specific areas. Thus, for example, the ability to disseminate and distribute digital information is a general capability or service, which in turn might be used in a number of areas, such as local, state, and Federal government, libraries, K-12 education, and social services. Given this scheme, we can then ask the dual questions "Which services will help us achieve each of our specific end goals?" and "What type of technology will best allow us to provide this service?" In this paper I outline one possible classification of community network services, and for each service attempt to give at least an initial answer to a set of key questions by which we can evaluate the service's suitability and feasibility for a community network. I have no illusions that what I say is by any means the final word on the subject (and in fact there are points in the paper where I just don't have a great deal to say); this paper is meant more as a way to spark discussion about the task of designing a community network, and as a guide to highlight various areas worthy of further research. This paper was originally written for the Washington, D.C., area community network CapAccess (the informal name for, and a service mark of, the National Capital Area Public Access Network, Inc.). I'd like to thank the other members of the CapAccess organization for their comments on early versions of it. However the views I express herein are mine alone and do not necessarily reflect the official position of CapAccess. I'd also like to thank Marilyn Davis, Andy Oram, and Doug Schuler for their comments on this paper. 2. SUMMARY OF SERVICES Let's start with a short list of services (online or otherwise) that could potentially provided by a community network. With each service we include the "real life" model whose function it's most reminiscent of: * providing a "raw" transmission facility over which people could send or receive any type of information and on top of which they could build higher-level services ("network provider") * collecting, generating, and disseminating information ("publisher" or "broadcaster") * taking information generated by others and redistributing it to others, whether end users or not ("distributor" or "wholesaler") * permanently storing information for later access ("library") * sponsoring discussion forums on topics of both general and specialized interest ("salon") * providing "gateway" access to remote systems and services ("public phone") * enabling people to send and receive personal electronic mail ("post office") * providing people with online work areas and document creation and manipulation tools ("personal office") * providing groups of people with online shared spaces to support collaborative work ("group office") * providing online mechanisms to enable the general public or specific groups to register their opinions and choices whether binding ("voting booth") or non-binding ("opinion poll") * training people to use online services and resources, including those associated with the Internet ("school") * assisting outside organizations in bringing "in house" the capabilities to provide online services and resources ("consultant") * providing overall management and/or direction for local and regional efforts to better serve the community through online networks ("systems integrator") Incidentally, note that when I say "people" I mean both people considered either individually, i.e., as members of the general public, or as part of formal or informal organizations separate from the community network and to which the community network may provide service. 3. KEY QUESTIONS The remainder of this document will discuss the various community network services in more detail, focusing on the following questions: * What characteristics distinguish this service from others? (How does one define it?) * What (overall) goals does the service promote? (What benefits will the service--if implemented--provide to the community?) * What are some actual or potential examples of such a service in the context of a community network? (Is anyone else doing this today? Could our community network do it?) * What "enabling technologies" could be used in providing this service? (What technologies are most relevant to this service?) * What issues must be considered with regard to interfaces, ease of use, and language and other cultural considerations? (Is everything based on plain English text typed in at keyboards, or should you provide WYSIWYG multimedia multlingual multimodel interfaces?) * What resources (technical or otherwise) are required to provide the service, and who (within the community network organization or otherwise) could supply them? (Is this something a community network organization can do itself, or is it better left to others?) * What types of end user information and access controls must the system maintain in order to provide the service? (Are there privacy issues or security issues relating to protecting user information or controlling access to system information or services? Do users need to register to use the service? How do they register?) [The above question should probably be stated more general in terms of security and privacy considerations.] * How do we measure the growth and quality of the service (in a relatively narrow technical sense)? (How do we determine whether the service is beneficial and is being used?) * What are the relevant "limits to growth" in expanding provision of the service? (At what point might growth impact the quality of the service? What would we need to do in order to continue growing the service while maintaining or improving its quality?) * How do we measure success in meeting the (overall) goals? (Has providing this service really made a difference in the community?) 4. PROVIDING TRANSMISSION FACILITIES ("NETWORK PROVIDER") 4.1. Definition By "providing transmission facilities" I mean building a (low-level) communications network and offering its services to others; by "low-level" I mean simply providing a "bit pipe" that can be used to transmit arbitrary data from point A to point B. 4.2. Relation to Goals Many people have conceived providing this type of service to be the main goal of the National Information Infrastructure ("wiring the nation") or even of community networking ("wiring the community"). However I believe that in the context of community networking the goal of providing this service is simply to make possible other higher-level goals. 4.3. Examples A potential example of this service is a community network establishing private data links (e.g., using TCP/IP routers and leased lines) from its system to those of local governments, to further the higher-level goals of enabling community network users to access local government information services and allowing government workers to participate more fully in community network activities. Another example would be building a private IP network consisting of "mini-LANs" in public facilities connected via ISDN links to the central community network system(s) and data network. This might further the higher goal of providing a high-bandwidth multimedia interface for public access stations. A pool of dialup modems and associated inbound phone lines can also be viewed as a simple transmission network. This facility could be potentially dispensed with if every potential end user had direct Internet connectivity through an Internet access provider separate from the community network itself. In this theoretical (at least for now) case, the only transmission facility required for the community network would be its own Internet connections supporting its own systems. (I further explore the implications of such an environment when discussing some of the other services.) 4.4. Enabling Technologies Enabling technologies for transmission facilities in community networks can be roughly classified into three "generations". The first generation is based on the public switched telephone network, using low-to-medium speed modems and plain old telephone service (POTS) to provide dialup login access. This is the mode of operation used by almost all BBSs and by community networks using, e.g., FreePort software. The second and current generation is also based on the telephone network, but now using either high-speed modems (14.4 and 28.8 Kbps) or ISDN connections (64 or 128 Kbps) to provide TCP/IP access using SLIP or PPP protocols. This technology is now being used on a wide scale by private Internet access providers, and could be used by community networks as well. The third and still future generation of transmission facilities is still in development. Exactly what it will consist of is still debated, but likely elements include very high speed (1 Mbps and above) links, possibly delivered using upgrade cable television technology. 4.5. Interface and Content Issues [To be written. One point may be that increased transmission speeds might help make possible higher levels of interactivity and richer forms of content.] 4.6. Resources Required The technical resources required to provide transmission facilities include communications links (e.g., leased telephone lines, cable coax links), communications hardware (e.g., routers and terminal servers), and communications software (e.g., TCP/IP protocol stacks for UNIX servers and PCs and Macintoshes). The people resources required include network designers and operations and maintenance personnel. In general these resources are best supplied by organizations in the business of providing communications services: local and long-distance phone companies, Internet access providers, cable companies, etc. 4.7. User Registration If a community network gets involved in building and maintaining its own transmission facilities mainly to connect to other organizations, then there would be little need to keep information about individual people, at least as far as network usage is concerned. A major exception to this is in the case where a community network might wish to ration the use of inbound dialup lines, and thus might keep track of how much "modem time" each person uses, in order to limit it to a specified amount per day or per week. 4.8. Measuring Growth and Quality One can measure the growth and quality of transmission services by such general measures as the number of sites and users supported, the amount of bandwidth provided (size of the "bit pipe"), the amount of traffic carried, and the availability of the service over time, as well as by more specialized measures such as the bit error rate, the propagation delay, the percentage of attempted connections completed, etc. 4.9. Limits to Growth The "limits to growth" in providing transmission services are determined by the underlying technology used (e.g., available bendwidth over copper wire vs. coax), the financial cost (both capital and recurring), and the people time to design and manage the system. For an organization not in the communications business there is also a significant opportunity cost associated with using resources to build infrastructure instead of providing higher-level services. 4.10. Measuring Success For a dedicated communications provider success in providing transmission facilities is typically measured in terms of revenue and profits. However for a community network success in providing transmission facilities is perhaps best measured in terms of the projects it makes possible that would not otherwise be possible. 5. GENERATING INFORMATION ("PUBLISHER") 5.1. Definition By "generating information" I mean creating information in digital form, either from scratch or by collating or editing existing information, and then disseminating it to others via various mechanisms. (For convenience I use the term "document" to refer to a packaged set of information; this could contain video or audio material in place of or in addition to text.) By "generating information" I do _not_ mean simply redistributing information generated by other online services (which I consider as a separate service); I assume that the community network has some significant role in preparing the content. I also assume that the value of the information in and of itself is to a large degree independent of the form it is in and the means by which it is distributed; for example, if a typical user received the information in the form of ASCII text files on floppy disks, it would be as fundamentally valuable (though perhaps not quite as easy to peruse and less aesthetically satisfying) as if they viewed it in fully-formatted form, including video and audio components, on a graphical workstation connected to the Internet via a high-speed link. 5.2. Relation to Goals Much of the current work of community networks involves the generation and dissemination of information of interest to the local community. Exactly how "the local community" is defined, and how we judge which information is of interest to it, are two of the major questions facing community networks. However in general the guiding principle is to provide information of use to the local populace conceived as citizens (as opposed to consumers, for example). 5.3. Examples Specific examples of information that could be provided by a community network include news of local government actions, library schedules, student writings and other creative efforts, contact information for local social service agencies, and so on. 5.4. Enabling Technologies Probably the biggest enabling technology in generating information is the set of hardware and software products supporting PC-based desktop publishing. (I use this term to mean not only producing four-color brochures and suchlike, but more generally to encompass any type of PC-based writing, editing, and production.) A second enabling technology which may become more important for community networks is the set of hardware and software tools for personal video production, which essentially promise to do for producing video material what desktop publishing tools did for producing print material. 5.5. Interface and Content Issues [To be written. Issues include text vs. text plus graphics vs. full multimedia. Other issues include content in multiple languages, different modes of delivery to compensate for physical limitations, compatibility with culural conventions, etc.] 5.6. Resources Required The technical resources required to generate and disseminate information include writing and editing tools and computer and communications facilities. The people resources required include editors, writers, and "subject matter experts" to provide the original content; for this type of service they are the most important resources. It's interesting to note in this respect that a community network could (at least in theory) do a perfectly good job of information generation and dissemination without providing any technical infrastructure of its own. For example, editors and writers could prepare material on their own personal computers, and the community network could then disseminate it using existing bulletin boards, other organizations' Gopher or World Wide Web servers or anonymous FTP sites, special-purpose USENET newsgroups, and so on. By contrast, on many present-day community networks there is only a single mode of information dissemination which depends on users having access to a central system. Even providing a Gopher server or anonymous FTP site would not change this, as remote Internet users would still have to connect to the community network's computer system one way or another in order to retrieve the information, and the performance and capacity of this system (and its associated network connection) would still limit the number of users who could be served. This suggests that a fruitful strategy for community network might be to "piggyback" on other online services to disseminate community network-originated information, in a way that does not depend on end users having direct or indirect access to the community networks' computers or communications facilities themselves. The community network then acts as a content provider rather than an access provider. 5.7. User Registration In many present-day community network systems we must also register users (which includes keeping authentication information, i.e., passwords) for them to receive information. If we disseminate information for redistribution by other online services, then we can reach more users without having to register them ourselves. For example, if we distributed information to local BBSs, end users would need only register with the BBS and not with the community network in order to view the information. In general, since community networks will presumably provide information at no cost, there would be little need to ever keep track of the end users of it (e.g., to charge them in some way). We simply have to ensure that the information "goes someplace" where users can get at it. 5.8. Measuring Growth and Quality One can measure the growth and quality of information generated and disseminated by a community network using such relatively objective measures as the number of documents published, total word (or byte) count, and the number and diversity of topics, editors, and writers. One could also gain a more subjective idea of the information's usefulness by, for example, doing end user surveys. 5.9. Limits to Growth The "limits to growth" in generating information are determined primarily by the variety of topics of local interest, and the number, skill, and productivity of the people editing and writing documents or doing video or multmedia production. Limits in terms of technical resources are less important, especially if piggybacking on other online services, as it is difficult to produce usable information faster than you can electronically disseminate it. 5.10. Measuring Success Success in providing information, at least for a community network, is perhaps best measured in terms of the difference it makes in the lives of its end users, i.e., the general public in the local community as well as those working in community organizations and institutions. 6. REDISTRIBUTING INFORMATION ("DISTRIBUTOR") 6.1. Definition By "redistributing information" I mean taking information in digital form from other online services (including other community networks) and then redistributing it either directly to end users or to other online systems. I assume that in this case the community network does not modify the information in any significant way, but simply takes it in from the source and sends it on to its destination. 6.2. Relation to Goals Although it does not generate new information as part of this service, the community network can add value in at least two ways: it can serve as a gateway between source and destination systems that would otherwise be incompatible, and it can store data temporarily while a destination system is down. 6.3. Examples A classic example of pure information redistribution is the function performed in the USENET conferencing system by so-called backbone sites, whose primary purpose is to collect USENET articles from submitting sites and then to retransmit them to receiving sites, so that all sites receive all articles. (Backbone sites may also originate articles, but these typically make up a very small percentage of the total volume passing through the backbone system.) Another example of information redistribution is "store-and-forward" mail hubs, for example as used in the X.400 messaging standard, which route mail between systems but do not send or receive mail themselves. (As a side note, "classic" Internet electronic mail is typically sent directly from the source system to the destination system, without passing through mail hubs. Mail hubs or gateways are used, however, when interfacing non-Internet mail systems, such as FidoNet or UUCP sites, to the Internet email network.) Currently many community networks do not practice automated information redistribution in any real way; information originates with community network volunteers, is put on the system's disk drives, and then read by users directly logged into the system. (Providing information by allowing users access to remote services such as Gopher and Web servers is not an instance of redistribution; it is an example of the community network being a pass-through gateway, as noted below.) One information redistribution scheme that some community networks have implemented is to have information distributed via email (e.g., as messages from LISTSERVs and related systems) be sent to a single address on the community network, from which they redistribute it to individual users. The main benefit of this is be to reduce the total number of messages sent to the community network's mail system. (The same mechanism could be used to redistribute the messages to users on other Internet-connected systems as well, but this would be relatively pointless since they could and should simply subscribe to have the information sent directly to the other systems.) A more complete example of information redistribution would be to receive LISTSERV or other messages and redistribute them to other systems without direct Internet email connections, such as BBSs or partner organizations' internal email systems. 6.4. Enabling Technologies [To be written. Include Usenet, mail-to-Usenet gateways, Usenet-to-Fidonet gateways, and so on.] 6.5. Interface and Content Issues [To be written. One key point is that gateways tend to enforce a least common denominator approach to the form in which information is distributed; thus the continued dominance of plain text without even font support.] 6.6. Resources Required The technical resources required to redistribute information include communications links both to the source and destinations systems, and gateway software to route messages and other information appropriately (including reformatting if necessary). In contrast with generating information, not much in the way of people resources is required; the main requirement is to install, configure, and maintain the necessary network links and software. 6.7. User Registration [To be written.] 6.8. Measuring Growth and Quality One can measure the growth and quality of information redistributed by a community network in terms of the number of "sources" (where information comes from) and "sinks" (where it goes to), total number of documents redistributed, and the diversity and quality of the information streams. The number of end recipients is also important, but in many cases will have to be estimated indirectly. 6.9. Limits to Growth The "limits to growth" in redistributing information are primarily technical, relating to the input and output bandwidth available, the processing power available for passing through documents and the complexity of format conversion (if necessary). 6.10. Measuring Success Success in redistributing information can be measured in terms of the extent to which the system is able to bring high-quality sources of information to users who would otherwise not have had access to it. 7. STORING INFORMATION FOR RETRIEVAL ("LIBRARY") 7.1. Definition By "storing information" I mean providing a permanent repository for information together with access methods by which end users may retrieve it; in essence the community network serves as an online library. 7.2. Relation to Goals We mentioned above that community networks may create and distribute information; they may also receive information from other sources. A great deal of this information has relatively long-lasting value, and by providing a permanent store of such information the community network can make it available far past the point at which it was originally created. The communnity network can also facilitate access to the information, e.g., to make it easier to search for relevent items. 7.3. Examples A classic Internet example of storing information is anonymous FTP sites: they store files semi-permanently, and have access methods by which users can retrieve them. There are even the beginnings of a public access catalog provided by such services as Archie. Although FreePort-based community networks also have permanent information files, they typically lack any good method for conveniently finding and accessing them. Files accessible via the FreePort menu structure can only be found by traversing through the system menu by menu until one finds the menu containing the item which when invoked will display the file. Many people have also attempted to use the FreePort forum system or related conferencing software to permanently store information files. This is doubly awkward: not only is there no easy way to find a file, but the USENET news software on which FreePort forums are based was designed to support relatively ephemeral conference discussions; it is ill-suited to permanently storing files. (For example, standard USENET news sites delete or "expire" articles after a relatively brief time. This expiration must be relaxed or disabled altogether to prevent valuable information from disappearing. However, turning off expiration also preserves unwanted article as well, whic must then be deleted using other means.) 7.4. Enabling Technologies [To be written. Mention anonymous FTP and adjuncts such as Archie, Gopher and Veronica, WAIS, and WWW.] 7.5. interface and Content Issues [To be written. Mention distinction between browsing and searching.] 7.6. Resources Required The technical resources required to permanently store and provide access to information include low-level facilities like disk drives and tape drives (for backup), as well as higher-level facilities like text-retrieval software. The people resources required include librarians (or their equivalent) to select information, categorize it, and provide interactive help to users. 7.7. User Registration Unlike a traditional library, in an online system there is no concept of "checking out" and "returning" documents. If we also assume that all materials are available to everyone at no cost and without restriction then there is no need in theory to identify and track individual users in any way. However, if the community network restricts access in any way, for example for minors versus adults, then the network will have to have a mechanism for identifying users at least to a group level. One might also want to track demographics data in combination with materials retrieved, for example to learn which materials are of most interest to which people and adapt the types of information stored accordingly. 7.8. Measuring Growth and Quality We can measure the growth and quality of information stored by a community network using objective measures, including the number of documents stored, total word (or byte) count, and number of user retrievals, as well as by more subjective measures. 7.9. Limits to Growth Some technical "limits to growth" in storing information include the amount of storage capacity available and the size and number of "pipes" by which users can retrieve the information. Other technical limits to growth arise from the complexity and performance of the software provided (if any) to allow the users to search for documents, e.g, by subject keywords. Other non-technical limits to growth arise from the need for people to do document selection and cataloging and to assist users in using the system to find what they want. 7.10. Measuring Success Success in storing information for access by users is mainly a function of useful the information is to users, and how easily they can find what they are looking for. 8. SPONSORING DISCUSSION FORUMS ("SALON") 8.1. Definition By "sponsoring discussion forums" I mean making possible (in one way or another) online conferences in which people can discuss issues of interest to them. Such conferences may be ongoing or may be one-time or periodic (e.g., annual or quarterly) affairs. 8.2. Relation to Goals A stated goal of many (if not most) community networks is to increase the participation of people in the public life of the community. Sponsoring discussion forums can enable this, by providing people a mechanism by which they can make known their thoughts to others and engage in dialogue with them. 8.3. Examples Some of the most well-known examples of online conferences are the various newsgroups of the world-wide USENET system; the "forums" in FreePort-based community networks are simply small-scale versions of these (and in fact are implemented using the same software). "Many to many" Internet and LISTSERV mailing lists also serve the same function, and also provide for the option of private "invitation only" forums. 8.4. Enabling Technologies [To be written. Include Usenet and related text 8.4. Resources Required The resources required to sponsor online discussion forums vary according to the role that the community network chooses to play in relation to the forums. In analogy with real-life forums, the community network can provide the "hall", provide the speakers, provide the audience, provide the moderators, or simply lend its name and prestige to the entire affair. In the online context, "providing the hall" might involve providing the combined hardware and software to support the online discussion, including mechanisms for storage and distribution of messages and tools for message preparation and reading. The resources required are mostly technical, with some people resources for, e.g., system administration. For some forums the community network may wish to have specially-chosen people participate in a major way, e.g., because they are experts in the subject matter being discussed, or have formal authority in government or other relevant bodies. The community network organization must then provide these people from its own ranks, must search for them among its users, or must recruit them from outside. We may also wish to influence the composition of the participants or "audience" for a given forum. This may be an active group of full participants or an audience in the passive sense. (Typically in online forums every participant has the ability to post messages and thus contribute to the discussion. However in many forums only a small percentage of users actually contribute messages, with the rest of the people for the most part simply reading what this small group writes.) If it is deemed important that the participants have particular characteristics (for example, that a forum on land use planning include a reasonable proportion of participants from affected areas), then the community network may make special efforts to advertise the forum and otherwise seek out people to participate. In certain cases the community network and/or the participants may wish the forum to be moderated, and the community network can help recruit people to do this. These may be either "rubber-stamp" moderators who approve messages for submission without otherwise doing anything, or they may be more active moderators who involve themselves in discussions and cut off unproductive topics ("threads" in USENET jargon). Finally, a community network may limit its participation to simply sponsoring an online conference or related online forum, lending its name to the proceedings and publicizing the forum as something worthy of note. 8.5. User Registration As with access to information, access to forums sponsored by community networks has often been subject to the restriction that you must login directly to the community network system in order to participate. There is really no technical reason why this should be so; forums could be distributed across multiple systems as are USENET newsgroups (and using the same software and distribution mechanisms). In this case users would have to register only as users of their home system; they would not have to register as conference users at all. With conferences based on mailing lists there would still be a requirement to subscribe to the list, and the list maintainer would have to maintain a permanent database of subscribers. Assuming that people subscribe under their own "names" as it were (not necessarily the case on the Internet), there then arise privacy issues regarding the handling of the list. Some online conferences may be "by invitation only" or otherwise not open to everyone; in such cases there would have to be qualification procedures to decide who will be allowed to participate. 8.6. Measuring Growth and Quality There are a number of objective measures by which one could measure the growth of online conferences. These include the total number of readers, total number of "posters" (people who contribute to the discussion), total number of messages or total volume of bytes posted, number of messages or bytes posted per person, and so on; many of these figures are currently being measured (to varying degrees of accuracy) on USENET today. Quality is a more subjective measure, and is often expressed in terms of a forum having a high "signal to noise" ratio; what constitutes "signal" versus "noise" is to a great degree a matter of opinion. However even here there are some identifiable characteristics that are often associated with a low signal to noise ratio--threads with many responses but little new material for each response, for example--and it may be possible to automatically compute a rough measure of this. 8.7. Limits to Growth Some limits to the growth of online conferences are technical: how many messages can be stored and transmitted on systems, how many people can access the conference, and so on. These are relatively minor factors, however, and the worldwide USENET system shows it is possible to build a very high-volume distributed online conference system reaching thousands of users. The more significant limits to growth are much more social in nature. For example, for most online conferences (even those with an audience of thousands) the number of people who seriously participate in conference discussions seems to be limited to a relatively small number (as low as ten or less for many conferences). As another example, even with the help of semi-automated filtering, the number of conference messages per day that people feel comfortable reading (much less responding to) seems to be limited to on the order of a hundred or so. On the other hand, a conference that has too few participants and/or too few messages per day will not generate sufficient interaction to attain a critical mass of discussion and dialogue. This suggests that the most successful online conferences will be general conferences with a very localized audience (at one end of the spectrum), or very specialized conferences with a nationwide or worldwide audience (at the other end of the spectrum). 8.8. Measuring Success The success of a community network's involvement in online conferences depends on the original goal. If the goal is to foster meaningful interaction among members of the community then success is perhaps best judged by the people themselves, often expressed as a feeling that they feel part of a special community online. (Along this line, Mike Godwin of the Electronic Frontier Foundation has a good article in the ? issue of _Wired_ magazine about the prerequisites of a online community.) In other cases the purpose of the conference is to produce some sort of deliverable (e.g., a joint statement of principles), and it is usually quite obvious whether that has been accomplished or not. 9. PROVIDING GATEWAY ACCESS ("PUBLIC PHONE") 9.1. Definition By providing "gateway" or "pass-through" access I mean giving people access to remote online and information services by allowing them to establish a session with a remote system or system providing such services. The community network adds little or no value in doing this; it simply serves as another in a set of alternative access mechanisms, perhaps cheaper or more convenient, but otherwise having no special distinguishing characteristic. Hence the analogy to a public phone: the user's main interest is in what sort of connections can be made, as opposed to any intrinsic interest in the system providing the connections. Such gateway access may be very tightly controlled (users can access only a few certain approved services), unrestricted (users can access any remote service of their choosing), or somewhere in between. 9.2. Relation to Goals Providing gateway access is often justified in general terms as increasing equity of information access ("helping the information have-nots"). It can also be justified more specifically as providing access to important services of interest to the community, such as remote library public access catalogs or Federal information databases. 9.3. Examples On many FreePort-based community networks gateway access is implemented by providing telnet connections to remote services such as library catalog systems. (Some of these in turn provide access to still more services; the WUGATE service at Washington University of St. Louis is one good example.) Many systems also provide Gopher clients or text-based World Wide Web clients such as Lynx, which can be used to access remote Gopher or WWW servers respectively. A more advanced example of gateway access would be a system which provided SLIP or PPP-based Internet access to end users. That is, it would allow users with SLIP or PPP-capable TCP/IP software to connect to the system as a full-fledged Internet node. Users connecting to such a system would be able to access any Internet-based remote service anywhere in the world. 9.4. Resources Required The resources required to provide gateway access are mainly technical in nature; they include some means for end users to access the gateway system (e.g., dialup phone lines and modems), the gateway system itself, and some means to connect from the gateway system to the remote service (e.g., an Internet connection). The gateway itself might be a full-fledged computer system such as a UNIX-based server; this is the case in FreePort-based systems. Alternatively, the gateway system might simply be a communications "black box" routing traffic from the user to the remote system; for example, in the SLIP/PPP-based system the gateway would be a SLIP/PPP-capable terminal server (more general known as a remote access server) which connects to incoming phone lines and modems on one side, and to a local area network (and through it to the Internet) on the other side. 9.5. User Registration Many services accessed through a gateway are inherently anonymous; that is, the user does not need to preregister to use the service. For other remote services the user must preregister, but this is really a matter between the user and the remote service; the gateway system itself (which is what the community network is operating) need not be involved in this transaction. Does this then mean that a community network operating a gateway need not worry about registering users (leaving aside for a moment the other services it might provide)? The answer in most cases is no, for at least three reasons. First, the community network may wish to ration gateway access, for example to avoid straining underlying technical resources such as dial-up lines. Such rationing is most easily done if users are registered and the amount of their usage controlled on a per-userid basis; for example, a given user might be limited to one hour a day of gateway access. Second, the community network may wish to restrict access to certain remote services for certain classes of users, for example, to provide a limited set of services for "guest" users or minors. (As a side note, however, if a community network allows gateway access to even a few remote Internet services, it is very difficult in practice to restrict access to other services. This is because there are a multiplicity of different access paths to services, and if users cannot connect to a service directly, they may be able to connect to a second service which allows access to the first; oftentimes these "back door" paths can get quite convoluted.) Finally, 9.6. Measuring Growth and Quality 9.7. Limits to Growth 9.8. Measuring Success 10. SUPPORTING PERSONAL E-MAIL ("POST OFFICE") 10.1. Definition 10.2. Relation to Goals 10.3. Examples 10.4. Resources Required 10.5. User Registration 10.6. Measuring Growth and Quality 10.7. Limits to Growth 10.8. Measuring Success 11. PROVIDING PERSONAL WORKSPACES ("PERSONAL OFFICE") 11.1. Definition 11.2. Relation to Goals 11.3. Examples 11.4. Resources Required 11.5. User Registration 11.6. Measuring Growth and Quality 11.7. Limits to Growth 11.8. Measuring Success 12. PROVIDING SHARED WORKSPACES ("GROUP OFFICE") 12.1. Definition 12.2. Relation to Goals 12.3. Examples 12.4. Resources Required 12.5. User Registration 12.6. Measuring Growth and Quality 12.7. Limits to Growth 12.8. Measuring Success 13. SUPPORTING ONLINE VOTING ("VOTING BOOTH" OR "OPINION POLL") 13.1. Definition 13.2. Relation to Goals 13.3. Examples 13.4. Resources Required 13.5. User Registration 13.6. Measuring Growth and Quality 13.7. Limits to Growth 13.8. Measuring Success 14. TRAINING IN INTERNET USE ("SCHOOL") 14.1. Definition 14.2. Relation to Goals 14.3. Examples 14.4. Resources Required 14.5. User Registration 14.6. Measuring Growth and Quality 14.7. Limits to Growth 14.8. Measuring Success 15. CONSULTING TO ORGANIZATIONS ("CONSULTANT") 15.1. Definition 15.2. Relation to Goals 15.3. Examples 15.4. Resources Required 15.5. User Registration 15.6. Measuring Growth and Quality 15.7. Limits to Growth 15.8. Measuring Success 16. PROVIDING DIRECTION/MANAGEMENT ("SYSTEMS INTEGRATOR") 16.1. Definition 16.2. Relation to Goals 16.3. Examples 16.4. Resources Required 16.5. User Registration 16.6. Measuring Growth and Quality 16.7. Limits to Growth 16.8. Measuring Success 17. SUMMARY [?]